http://nintendoage.com/forum/ -Sqooner http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=90320 2012-12-06T11:32:51 -05.00 acidjaguar 33 http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=90320 2012-12-05T20:58:34 -05.00 acidjaguar 33
]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=90320 2012-12-05T15:36:39 -05.00 acidjaguar 33 Originally posted by: MottZilla

So what happens is the CPU is not yet done calculating everything so when the NMI happens, it checks to see "do I have a frame update ready?" and it will see that no, the main thread has not yet completed its calculations. So what happens? It has no video update and lets the main thread continue. The result is for this frame, we had no update so the game appears to slow down.

This is what I was trying to explain, except you can also let the game slowdown by disabling the NMI interrupt at the beginning of main code, and enabling NMI at the end, so that the CPU doesn't get interrupt.  I just mistakenly called NMI "IRQ" in my last post. ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=90320 2012-12-05T14:45:54 -05.00 acidjaguar 33
The game is running fine but for some reason new objects are now on the screen and it's going to take more time for the CPU to calculate everything that is happening. So what happens that you should understand is this. The CPU and PPU (graphics chip) are separate. The PPU will run even if the CPU weren't running. The PPU runs constantly in a loop drawing scanlines. When the PPU is drawing scanlines, the CPU cannot access VRAM, meaning it cannot alter what appears on the screen (tiny exceptions exist). So the system has an interrupt called NMI. This happens every time the PPU finishing drawing the frame. At this point there is a very small window called Vertical Blank. During this time the VRAM and scrolling and other parameters can be updated. So what happens is the CPU is not yet done calculating everything so when the NMI happens, it checks to see "do I have a frame update ready?" and it will see that no, the main thread has not yet completed its calculations. So what happens? It has no video update and lets the main thread continue. The result is for this frame, we had no update so the game appears to slow down. Some of this language or details are not exact but this is the premise to make it easier to understand.

So, when the CPU load is light, every time the PPU is done drawing the CPU gets to update the video frame. However when the CPU load is too heavy, the CPU doesn't have a frame update ready in time when the PPU is done drawing and this frame is lost so the same frame is displayed again which in motion looks like slowdown.

Pegboy, your theory is correct. Without the program doing anything to compensate the result would be sprites after the 8th being invisible. But the games are programmed to prevent this usually, which results in as you say, they change each frame which sprites get drawn and the result is flickering when there are more than 8 sprites on a line. ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=90320 2012-12-04T16:56:00 -05.00 acidjaguar 33 Originally posted by: pegboy

Isn't the sprite flicker just a result of the 8 sprite/scanline limit? So they interleave the sprites every other frame to display more at a time? I'm not a expert.

Yes.  Some people just like to blame everything on the CPU.
]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=90320 2012-12-04T15:24:31 -05.00 acidjaguar 33 http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=90320 2012-12-04T13:54:34 -05.00 acidjaguar 33 Originally posted by: MottZilla

Flicker of sprites has nothing to do with the CPU. This is just like that rumor I saw all over saying that "slowdown in games intentional so the game doesn't crash".
 

Why haven't I heard that rumor before?  I've heard a lot of rumors about CPU speed and slowdowns, but not that one.  There is a hair of truth in it, because from my experience, in order for it to automatically slowdown when needed, you have to keep the NMI interrupt disabled, until the end of the main routine.  If the NMI is kept enabled throughout the frame, the NMI will cut the CPU off in the middle of the main routine, causing glitches and possibly even a crash.

EDIT: Accidentally got NMI and IRQ mixed up.  Fixed. ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=90320 2012-12-04T10:59:30 -05.00 acidjaguar 33
You know since I'm not a programmer or started down that road yet I will be simply getting a retrogen to play my old faves ...

Thanks for the quick run down Aaendi and I will revisit this if I decide to give it a go. Thanks everyone for your input ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=90320 2012-12-04T10:50:09 -05.00 acidjaguar 33
Color Palette: Round each Genesis color to it's nearest SNES color. Have a copy of the color palette available for both sprites and BGs to use.

Resolution: Just try to adjust the title screens and HUD to fit within 256x224. BGs and sprites can be left unmodified. If a boss fight uses a "level" that is just one 320x224, horizontal scrolling can be added.

Animation: Now this one is a tough one. The Sega Genesis has a bigger chunk of vram designated to sprite animation and faster DMA. My solution is to keep 16 pixels of fored blank on top and bottom of screen, so you can use DMA more. If there is already a HUD infront of a black bar, take advantage of the already small playfeild size, and move the HUD onto BG3.

Sound: Make a sample of every sound you use in the game.

Gameplay: You pretty much have to recode gameplay entirely from scratch. ]]> http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=90320 2012-12-02T18:50:54 -05.00 acidjaguar 33
The Master System had a following in Europe mostly but there were those in the US and Japan that had it. I'd say they should have kept BC only for the European MegaDrive and cut it out of the NTSC version to cut cost to improve the color situation. But we can say whatever we want now knowing all that we do that they didn't.

The Genesis needed to have eight 16 color palettes at a minimum in my opinion. SNES had plenty, TG16 had tons. But Genesis was too few for sure. Doubling it probably would have made it far less noticeable of an issue. ]]>