Home Page Forums MAME MAME The SNES WIP topic

which handlers? the current emulation works as follows:

at the end of each scanline we update the OAM parameters that should be used for the next line; then we pass through OAM RAM, checking which sprites will be drawn in the scanline (and setting the flags if there are too many sprites); finally we draw the scanline (both BG layers and sprites). notice that RTO flags are not reset until next frame (and indeed the flag reset happens in a timer which is called at the beginning of the frame).

how do you suggest to re-implement it without breaking sprite limits?

RTO is a SNES register flag, right?

So move/calc the OAM params in that specific register and change the value accordingly.

could you take a look at snes_update_objects_rto? I cannot see exactly your idea would fit the SNES behavior (which is not something I made up, it's the way byuu describes and implement it, and he ran *a lot* of test on the hw about this flag): the flag can be updated at each scanline, not only when the register is accessed by the snes_io handler. also, notice that snes_oam is going to be a PPU thing only.
maybe we could add an handler which writes back to the register from the PPU, but would the handler be called at the right moment by the video_update?

Well the entire reason I don't use Video Update for anything in Genesis apart from copying a bitmap is so that the sprite collisions flag etc. works as expected. (I'm aware that it makes merging it with S18 harder, but that's tough)

My scanlines are rendered with timers, and to be honest, if you're going to do the brightness trick for that shadow which byuu points out then your only option is going to be using your own timers. Video Update has no concept of partial-scanline updates, and your code would need to at the very least be able to render a partial scanline up to the point where the brightness gets changed. (calculating the time since scanline started based on the timer, thus knowing the point at which the cpu changed the data)

If you've done C64 I'm surprised you don't know this tho? Afaik C64 makes extensive use of mid-scanline updates for some of the demos, which MAME can't handle with partial updates.

in fact, robiza has done all the video work on c64. I mainly cared about carts and tapes and memory banks (and to some extent floppies, until Curt came and made it better and faster)

and I know that flags can have problem with video updates, but I'm not so sure I can handle a complete rewrite by using timers at the moment, while I was more than capable to improve the original code until reaching the current level of accuracy (which is not bad, all considered)

now that the problem has surfaced, I added to my todo list the investigation of a timer-based rendering rewrite, but it won't happen anytime soon (especially because the current code is good as long as you don't frameskip, and it works pretty well even when you skip frames if the game is not too strict)
snes is definitely more in need of CPU timing fixes than this RTO flags problem...

If you want to see a simple video system that renders partial scanlines via timers see the sam coupe driver (just to give you some pointers).

MAME does have a flag which causes no frameskipping to be allowed in the drivers, but I found it to be unreliable (I can't remember exactly what the issue was, might have had something to do with the debugger, or partial updates)

As a temporary fix you might be able to use that, but it won't give you the long-term flexibility you need.

my plan is: convert the ppu to be a device, see if I can fix any issue in games which don't start, and then take a break from this driver (waiting for cool things to happen on the CPU and timing side).

once RTO issues will be relevant in the currently huge buglist, I will put the video rewrite on top of my todo list.
with current svn, we now almost compare line-per-line code and output of MESS vs. bsnes and I already see this as a quantum leap compared to the 0.136 source code (not to mention the number of bugs that have been solved and the missing effects that have been added in the meanwhile)

etabeta78: you were working on the NES ppu stuff as well, right? Is there any chance you can get rid of the lookup tables in src/mame/machine/vsnes.c and just require for all vsnes games, a rom which contains the 9-bits-per-color color lookup for said game?
The lookup tables remap the 'scrambled' vs nes ppu roms back into the closest available colors in the normal ntsc-generated color spectrum, which is completely and utterly wrong to hardware.

Proposed function would be vsnes_get_color which takes the color index, the ppu type, and the color de-emphasis bits and monochrome bit for input, and returns an RGB color.

LN

yeah, I plan to work a bit more on NES as well, but let's remain in topic and discuss NES problems in the NES topic, when I'll be back to that driver...