|
Display information vs screen dumps
#150903 - 05/03/08 10:33 PM
|
|
|
What does the new attributes in display mean?
I'm talking about htotal, hbend, hbstart etc.
Take 'amidar' for example. The width is 768 according to the mame info. With rotate at 90, that would be that the height value is for the width and the width is for the height. That would give a height of 768.
The height of 224 becomes the width and that's correct, but my screen dumps have a height of only 256. I'm thinking that the other attributes have something to do with it, but I can't figure it out.
Anyone that can help me? 
|
|
|
Stiletto |
|
They're always after me Lucky ROMS!
|
|
|
|
|
|
Reged: 03/07/04
|
|
Posts: 6472
|
|
|
|
|
|
Send PM
|
|
|
Re: Display information vs screen dumps
[Re: BartA]
#150919 - 05/04/08 09:23 AM
|
|
|
> What does the new attributes in display mean?
> I'm talking about htotal, hbend, hbstart etc.
>
> Take 'amidar' for example. The width is 768 according to the mame info. With rotate
> at 90, that would be that the height value is for the width and the width is for the
> height. That would give a height of 768.
>
> The height of 224 becomes the width and that's correct, but my screen dumps have a
> height of only 256. I'm thinking that the other attributes have something to do with
> it, but I can't figure it out.
>
> Anyone that can help me?
They are raw video parameters. Are you familiar with video "modelines" in Linux, etc?
width, height, refresh should be obvious.
pixclock is the pixel clock.
htotal is the total horizontal lines (htotal = width + right border + hsync + left border)
hbstart is HBLANK (horizontal blank) start, the pixel number in which to start horizontal blanking. Measured from the leading edge of H sync.
hbend is HBLANK (horizontal blank) end, the pixel number in which to end horizontal blanking. Measured from the leading edge of H sync.
vtotal is the total vertical lines (vtotal = height + top border + sync + bottom border)
vbstart is VBLANK (vertical blank) start, the pixel number in which to start vertical blanking. Measured from the leading edge of V sync.
vbend is VBLANK (vertical blank) end, the pixel number in which to end vertical blanking. Measured from the leading edge of V sync.
Amidar has:
width: 768
height: 224
refresh: 60.606061 Hz
pixclock: 18432000 (Hz)
htotal: 1152
hbend: 0
hbstart: 768
vtotal: 264
vbend: 16
vbstart: 240
Given htotal and pixclock, we can derive HFREQ or the horizontal refresh rate
HFREQ = pixclock / htotal = 18432000/1152 = 16000 = 16 kHz
Also, HFREQ = VFREQ * vtotal
so VFREQ = 16000/264 = 60.606061 Hz.
For more info, read info on Linux modelines such as:
http://howto-pages.org/ModeLines/
http://easymamecab.mameworld.net/html/monitor1.htm
http://linuxconsole.sourceforge.net/fbdev/HOWTO/3.html
Modeline calculator (Python): http://svn.pardus.org.tr/uludag/trunk/comar/zorg/zorg/modeline.py
---------------------
Now that you've read all that and understand what HBLANK, VBLANK, HSYNC, VSYNC, and so on are, to understand further Amidar's case, go read the source - this is one of the cases where it's extremely well documented as it was rewritten from schematics.
http://mamedev.org/source/src/mame/video/galaxian.c.html
http://mamedev.org/source/src/mame/drivers/galaxian.c.html
This explains why your screenshot is 256x224 but the "resolution" is 768x224. The screenshot is the actual pixel-by-pixel screen dump, the resolution is including all the timing information (we're going by the 18.342 MHz "master clock" (in the info case the pixel clock), which is divided by three to provide a 6.144 MHz signal that drives the video logic, described as "pixel clock" in the driver. What is 256 times 3? 768.
And remember this basic equation, where HFP = "Horizontal Front Porch", HBP = "Horizontal Back Porch" and HDISP = "Horizontal Displayed pixels", active area, whatever:
HTOTAL=HSYNC+HFP+HDISP+HBP=HBLANK+HDISP
HBLANK=HSYNC+HFP+HBP
Ergo:
44 pixels front porch
32 pixels horizontal sync
44 pixels back porch
6 pixels left border
256 pixels video
2 pixels right border
---
384 pixels total per line
And scaled from 6.144MHz to 18.432MHz?
132 pixels front porch
96 pixels horizontal sync
132 pixels back porch
18 pixels left border
768 pixels video
6 pixels right border
---
1152 pixels total per line
But given the measurements from schematics in the source code, it's actually:
42 pixels front porch
32 pixels horizontal sync
46 pixels back porch
6 pixels left border
256 pixels video
2 pixels right border
---
384 pixels total per line
And scaled from 6.144MHz to 18.432MHz?
126 pixels front porch
96 pixels horizontal sync
138 pixels back porch
18 pixels left border
768 pixels video
6 pixels right border
---
1152 pixels total per line
Or something like that. I probably got the front porch and back porch flipped. 
There, I think I got all that right. Late at night when fueled by caffeine and adrenaline, I enjoy taking on questions like these that aren't quite my usual cup of tea. I'm sure Haze or couriersud or someone will be along to nitpick later. 
[EDIT] Oh yeah, and Galaxian's resolution was doubled because of the stars:
http://mametesters.org/mantis/bug_view_advanced_page.php?bug_id=199
So... that would be an actual game resolution of 128x112 except the stars are literally 0.5 pixels, so we doubled the resolution for our emulation. I think.
- Stiletto
Edited by Stiletto (05/04/08 11:16 AM)
|
|
|
|
Re: Display information vs screen dumps
[Re: Stiletto]
#150922 - 05/04/08 11:23 AM
|
|
|
This is too much for my small brain 
> This explains why your screen shot is 256x224 but the "resolution" is 768x224. The
> screen shot is the actual pixel-by-pixel screen dump, the resolution is including all
> the timing information (we're going by the 18.342 MHz "master clock" (in the info
> case the pixel clock), which is divided by three to provide a 6.144 MHz signal that
> drives the video logic, described as "pixel clock" in the driver. What is 256 times
> 3? 768.
I saw the 256 - 768 relation, but the why is still not clear.
To explain why I want to know:
I made and host http://www.mamescore.net where players can submit their high scores and add a little bit of competition to the fun of playing MAME.
As part of the high score validation, players must submit a screenshot of the high score (done with F12).
To display the screen shots I take the width and height attributes of the display tag. (actually, I inserted all the information in a database).
In the past, this information was like this:
< video screen="raster" orientation="vertical" width="224" height="256" aspectx="3" aspecty="4" refresh="60.606060"/ >
And it was easy to get the width and the height, but now my windows sometimes look weird.
So, although the technical stuff is very interesting, I don't need it for my problem. I need a 'simple' equation to calculate the 'normal' width and height of a screenshot.
Edited by BartA (05/06/08 12:27 PM)
|
|
|
|
Re: Display information vs screen dumps
[Re: BartA]
#150931 - 05/04/08 03:11 PM
|
|
|
@Stiletto: This is a really nice tutorial on timing. This belongs on the Developer Wiki.
--
The galaxian driver triples the horizontal resolution to render the stars correctly. Thus instead of 256x224 you get 768x224.
There is currently no way to determine this fact directly from the xml information which you also display on your side. You have to force an aspect ratio of 4:3 in this case.
Pseudo code:
aspect = x / y
if (abs(aspect - 4/3) > 0.2 ) // choose your trigger
{
x = y * 4 / 3
or
y = x * 3 / 4
}
Galaxian : x = 768, y= 224
aspect: 3.43
==> (aspect - 1.33 ) > 0.2
==> x = 224 * 4 / 3 = 299
If you do not want to loose information, just do
y = 768*374 = 576
BTW, i just figured out sdlmame is having an issue with the tripled resolution as well.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Display information vs screen dumps
[Re: BartA]
#150939 - 05/04/08 07:30 PM
|
|
|
> I made and host http://www.mamescore.net where players can submit their high scores
> and add a little bit of competition to the fun of playing MAME.
> As part of the high score validation, players must submit a screenshot of the high
> score (done with F12).
You've heard of MARP, right?
|
|
|
|
Re: Display information vs screen dumps
[Re: BartA]
#152695 - 05/26/08 08:54 PM
|
|
|
Going with the topic, some games can be misleading with the listed screen sizes. For instance, games using PSX based hardware can actually use anything from 256, 320, 368, 512 and 640 across and either 240 or 480i lines at any given time. In this example, MAME just writes the maximum value of the game's pixel size. The correct size is always displayed and the screenshot will always come out the right way. A lot of PSX games tend to use 512x240 in-game, but might switch to 320x240 in the test/operator mode or when a video plays for instance.
|
|
|
|
Regarding the highscore site
[Re: BartA]
#152709 - 05/26/08 11:30 PM
|
|
|
Looking at the site, I noticed it had the Tekken series listed in there. There aren't actually any high scores which can be made in these games, as anyone can easily rack up 99 wins in vs. mode against a 'dummy' (not used) player 2. I'm not sure if these games could even be added since every character used, and randomly fought against, is completely different.
Does the site support 'low' scores, such as time records? This would be very useful for the racing genre among others.
What is needed is a standard game-dependant rule for on each page above the scores, showing the default 'factory' options and the rest. Games like Tekken 2 can't really be started from scratch (e.g. erased NVRAM) with default settings, as the 13 extra characters would end up going missing from the list. Being a character based game, there would also have to be a separate record for each character. Also, since the characters aren't just different versions of the same player like Mario and Luigi in Super Mario 1 for instance, it would be needed.
|
|
|
|
Re: Display information vs screen dumps
[Re: couriersud]
#158645 - 07/25/08 02:26 AM
|
|
|
> The galaxian driver triples the horizontal resolution to render the stars correctly.
> Thus instead of 256x224 you get 768x224.
Fucking annoying too. It makes scorpion *crawl* on my laptop, and you can guess how fun it is to work on sound when the game doesn't reach 100% anymore.
OG.
|
|
|
Previous 
Index 
Next 
Threaded 
Display information vs screen dumps
Reply
[Re: 
