I need the list of systems emulated by VBA, and for each of them, the image sizes of the typical screen in pixel.
Current I have:
+---------+-------------------------------+-----+-----+-----+
| abbr | name | x | y1 | y2 |
+---------+-------------------------------+-----+-----+-----+
| NES | Nintendo Entertainment System | 256 | 224 | 240 |
| SNES | Super NES | 256 | 224 | 240 |
| Genesis | Sega Genesis | 320 | 224 | 240 |
| GB | Game Boy | 160 | 144 | 144 |
| SGB | Super Game Boy | 256 | 224 | 240 |
| GBC | Game Boy Color | 160 | 144 | 144 |
| GBA | Game Boy Advance | 240 | 160 | 160 |
+---------+-------------------------------+-----+-----+-----+
(Yes, the site ignores the fact that there are 256xN Sega games)
This information is needed by the site engine to group movies by system and to render the movie list properly.
Most specifically, I'm interested of:
- Whether it would be better to group some of those systems together
- Whether the maximum image sizes are wrong (because of border, maybe?)
SGB games are 256x224 with the border, or 160x144 without the border. SNES games can have anywhere between 224 and 240 pixels of height, but I don't think SGB games ever make use of more than 224 (or if they do then VBA never emulates that). Besides that everything looks right.
Some games have data for GBC, SGB, and GB systems in them, but typically such games should be recorded for GBC, or SGB if that's not available, with GB being the last choice. In general there's no reason such games should behave the same for all 3 systems although that's probably intended most of the time. Anyway, if you're going to group anything together it should probably be those 3 systems, but I think it'd be better to have the individual system shown.
Unnecessary lag? I don't think any of the changes that still need to be made involve changing the timing of the game. If you mean the sound lag, that's just DirectSound lagging in playing the sound that's already being emulated with the correct timing, and that wouldn't even go into an AVI (because the raw sound is outputted directly and combined with the video later, no waiting for something to play it. The only problem now is I'm not sure how to verify that the output is correct so the video output is messed up (currently reading the "Converting *** to AVI" pages to see if anything there helps with that.) As for the frame rate, I can't find any indication that the emulator uses anything but 60 fps for all games.
Oh, I was just referring to a couple of Game Boy Advance games where people said that they slow down on VisualBoyAdvance when they don't slow down at all on a real Game Boy Advance. As though VBA were underestimating the processor or something.
put yourself in my rocketpack if that poochie is one outrageous dude
But the AVI problems need Nitsuja's attention.
Also, there was a question regarding the file format, which requires his attention.
See the links in my previous post.
Is that question just about the 12-byte character array (oh, well if not, the following also applies to the "Info" section too)? Yes, it's 1 byte of ASCII per character (left to right in the file), taken directly from the ROM. z is 122, ä is 228 (and the other character you asked about just shows up as a box for me). The 4-byte game code is also parsed as ASCII when it's displayed, but it's treated as an integer otherwise. (These are only used by the emulator to show if ROMs mismatch, there's no title information good enough to pull out of the file directly to get the game name or ROM filename.)
I noticed in the code you posted, it always outputs to test0.avi even if you tell it at the commandline to output it somewhere else, I changed this but you changed it back in version 2, so was this the desired behaviour?
Do you know of anything (that works in Windows) that can display the uncompressed AVI frames that are outputted? It looks like you're printing some AVI header information, but I can't find any video player that recognizes the format. I'm also not sure if the color format is correct, you said you assume 16-bit color but there are a lot of variations of how 15/16-bit color can be stored.
About the slowdown, I don't know whether it's a problem, but I wouldn't know how to fix it if it was. I doubt it's as simple as them accidentally setting a clock frequency variable too low.
Yes, it's 1 byte of ASCII per character (left to right in the file), taken directly from the ROM. z is 122, ä is 228 (and the other character you asked about just shows up as a box for me).
I noticed in the code you posted, it always outputs to test0.avi even if you tell it at the commandline to output it somewhere else, I changed this but you changed it back in version 2, so was this the desired behaviour?
I don't understand what you mean. Or maybe that was an obsolete question?
I'll see about the author info formatting. Right now it's just putting whatever text Windows reads from the text field into the string.
About my question, that was back when it opened the file in the constructor which made it always open with default args before I could set the arguments as it was a global static object. It's appears to be fixed now.
Oh, I always referred to that as "Extended ASCII"...
Extended ASCII (IBM's term) is CP437 (below), not ISO-8859-1 (compare to above).
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜ¢£¥₧ƒáíóúñѪº¿⌐¬½¼¡«»░▒▓│┤╡╢╖╕╣║╗╝╜╛┐└┴┬├─┼╞╟╚╔╩╦╠═╬╧╨╤╥╙
╘╒╓╫╪┘┌█▄▌▐▀αßΓπΣσµτΦΘΩδ∞φε∩≡±≥≤⌠⌡÷≈°·•√ⁿ²■
Edit: I meant CP437, not CP850.
Right, I forgot about all those cool block and line characters that you can make boxes and fades out of.
Say, can't the first 31 or 32 characters be displayed as visible symbols, too? I know it was the case in ZZT...
put yourself in my rocketpack if that poochie is one outrageous dude
Say, can't the first 31 or 32 characters be displayed as visible symbols, too? I know it was the case in ZZT...
They're control characters, such as backspace, newline, tab and so on.
It was possible to have symbols in them on the PC textmode where the bytes were directly poked to the display RAM, but not any longer in the world of protocols.
Darn. I'm gonna miss those chicken nugget smiley faces... And those playing card suits... And that pair of sixteenth notes that had the misfortune of sharing its code number with carriage return...
put yourself in my rocketpack if that poochie is one outrageous dude
Darn. I'm gonna miss those chicken nugget smiley faces... And those playing card suits... And that pair of sixteenth notes that had the misfortune of sharing its code number with carriage return...
I just noticed the front page has changed - I take it GB/GBA submissions are being accepted now? (The AVI output finally works?)
(As a quick answer to BoltR's question about the slowdown: I found a small table of values in the (nearly-uncommented) GBA core that determined how long to wait after doing a memory transfer, which happens frequently when new enemies or levels are coming onscreen. Memory access certainly takes some amount of time, and I have a feeling their values were accurate, but I think they weren't taking into account something like the GBA being able to simultaneously process something else while the memory is being accessed, so returning 0 instead of the values in the table actually seems to give a much better approximation of the correct timing.)
Also, please note that byte 0x017 in the VBM header format has just changed: bit 3 stores 0 if the old laggy timing is enabled, 1 otherwise.
Argh, I wonder what it could be this time? I'll look at it later when I've found out... I should note that (assuming you're able to get output anything like mine) games might sound like the audio is coming out a little too early, but that's only compared to listening to it in the emulator with its sound buffer delay time - I think it's actually correctly synchronized or within 1 frame of it.
