New Super Famicast & NesterDC SE releases imminent

[BlackAura]

scherzo - GCC supports branch prediction hints, which you can use if you know a certain piece of code is (un)likely to be executed.

Have a look at this message (first Google hit, which turned out to have some useful info):

http://sources.redhat.com/ml/sid/2001-q1/msg00072.html

[scherzo]

Thanks BA. At least that's some control as opposed to crossing your fingers and hoping you get a good compile each time. Maybe I could put this in certain places such as SuperFX and SA1 specific code since nearly all games don't have those chips. Perhaps elsewhere in the graphics code too. Even if it's a frame or two better, it's still something.

[Ian_micheal]

Yes some times out of no were i get a much faster build. Thanks for telling me why was starting to get to me. I compiled a build of a project 2 times it hit 21fps the other times 14 fps thats a big drop thats some thing compiled 10 times.


Best setting on neogeo sdl/cd brings a lot of speed and fixes the grafix display is this


-O9 -fomit-frame-pointer -freorder-blocks -funsigned-char

I use it on a lot of things.

[Kamjin]

Just a small shift in topic..

Scherzo, I hope nothing I posted offended you, and if
it did my appologies..

Just to restate..
The CPU core in C is fine, since most of the opcodes are
not passing params (global CPU), and you have all the
subfunctions as inline, you're not going to gain by using
assembly.

I only looked at the cpu, and a bit of the dma code, where are
you placing the backbuffer, as you build it system/video ram?

[Ian_micheal]

Yeah I looked at the cpu core and noticed that but really was not listened to. Sh4 core would make little change. Kamjin is there any thing you can see in neogeo cd for optmizing.

[scherzo]

The snes9x system requires you to create a buffer that receives the rendered image. I create this buffer in system memory and copy that to video memory. Video memory is also quadruple buffered itself which is a method I stole from NesterDC code. So there are four different pvr textures that are written to, not at the same time of course, just a diferent one each frame. Of course, that quadruple buffering is what causes the perceived input lag of NesterDC. I'm going to change this to only double buffering and see if that improves that input lag.

I don't think that how I'm rendering the image once snes9x has put it in a system memory buffer is a source of slow down. It's the snes9x code that builds that offscreen image. My current code has the ability to enable/disable sprites and backgrounds through the in-game menu. As you do so, you notice the frame rate pick up. Super Mario world for instance runs nearly full speed if you turn off 3 of the 4 backgrounds. If you turn everything off, it does run fullspeed. So the cpu core in C is actually fast enough. I just thought in the beginning that rewriting the cpu core, although fast anough, would give even more time to other things like graphics. This is true, but it won't give as much as focusing on graphics itself.

I've also tried to have my pvr rendering code run in a seperate thread so that the blocking aspect of pvr_ready and pvr_wait wouldn't slow down emulation. It would actually run a little bit slower. I believe the state switching of KOS's thread system was more expensive than what I might have been gaining. Multithreading is a convenient construct but not the most efficient on a system like the Dreamcast, I think.

I'm going to work hard to get my most current code and binaries out very soon so we're looking at all the same stuff.

[scherzo]

Also, does anyone here use the dma transfer functions successfully? Every time I try it, it freezes up on me. I call pvr_dma_init() in main and try to use pvr_dma_transfer instead of sq_cpy. It just doesn't work. Any thoughts?

[Ian_micheal]

I like to help on that but It allways did the same to me. Black aura knows Pvr DMA very well genesis plus source has an example that could be handy to you.

[scherzo]

Thanks, I'll see if I can find it.

[scherzo]

Well, I took a look at his code and he doesn't even call pvr_dma_init but I guess everything works. And pvr_txr_load_dma in KOS 1.2 takes less parameters that the current subversion of KOS. There are parameters for a callback function that gets called when the dma transfer is completed. Ah, screw it. I'm going to eat, sleep, and make love to the gfx code until I am it's master.