SNES emu in the works

[Strapping Scherzo]

If I'm not mistaken, Sintendo was developed using the official WinCE Dev Kit for Dreamcast. And I remember how slow it was too so I doubt any parts of it were written in assembly. I just glanced through the source; Nothing. Thanks for the effort though.

[SSJKarma]

is it just me or you said you used 640x480 ?

if so then why ?
isn't it better for speed to use the original SNES resolution which is something like 300 X 256 or something like that ?

just to know, because speed wise i think its better to use the actual SNES resolution, but what do i know, after all i'm the one no one knows around here !

just a question, you said last timew that you had a great deal of speed for a while, or did i heard it wrong ?

what are the SOUND resolution ?
can we have a few details on the configuration you are testing on ?

[Ender]

is it just me or you said you used 640x480 ?

if so then why ?
isn't it better for speed to use the original SNES resolution which is something like 300 X 256 or something like that ?

Apparently with how the hardware works, there's minimal difference between the low resolutions.

[Strapping Scherzo]

Well, the SNES resolution was 256x224. The DC does not have a mode for that resolution. It does have 256x256, but as far as I can see it's a PAL only mode. Next highest resolution is 320x240, which has both NTSC and PAL modes. But if you want to stretch the 256x224 to 320x240 for full screen display, it'll look pretty ugly since those resolutions are too close to one another. It wouldn't just be pixelated. It would be jaggy and crappy. Of course, you can throw fullscreen stretching out the door and settle for black borders around a SNES image that is pixel for pixel. I tried that and there was no noticable speed difference between that and the 640x480 mode. In 640x480, if you stretch the 256x224 image fullscreen and enable the PVR's bilinear filtering, the image looks very nice and it's fast. It really doesn't matter what resolution I run at. The DC's PVR stretches the texture nearly instantaneously no matter what. In fact, it's really an easy job for the PVR considering that it only has to draw two textured triangles (I could explain that but I would have to get into stuff that should be in the Programming Forum). And it's capable of 3.5 million polygons/sec.
There's one slow thing involving the graphics that simply can't be avoided, and that's updating the video memory with the new frame. The data transfer between the SH4 and the PVR memory is not as fast as SH4 and it's own memory. But if you want to see your game, it has to be done.

Great deal of speed? Well, so far, different games run at different speeds. The slowest I've seen is 5 fps and the fastest is around 40 fps. One game I like testing is Street Fighter II: The World Warriors because it performs nicely and is very playable.

As for sound, I worked on that tonight but still haven't got it working yet. It's pretty complicated. I envision that you, the user, will be able to change the sound rate and disable it altogether. I just have to figure out how to enable it first!

[sheng]

MY LATEST CREATION! (thx InsaneDavid for the Famicast logo and to Sheng for the icons)

and yes Scherzo, it's in BMP now

http://www.geocities.com/mkil1a/mkil1a. ... 4138603908

Wow it's really good!

[Ender]

Well, the SNES resolution was 256x224. The DC does not have a mode for that resolution. It does have 256x256, but as far as I can see it's a PAL only mode. Next highest resolution is 320x240, which has both NTSC and PAL modes. But if you want to stretch the 256x224 to 320x240 for full screen display, it'll look pretty ugly since those resolutions are too close to one another. It wouldn't just be pixelated. It would be jaggy and crappy. Of course, you can throw fullscreen stretching out the door and settle for black borders around a SNES image that is pixel for pixel. I tried that and there was no noticable speed difference between that and the 640x480 mode. In 640x480, if you stretch the 256x224 image fullscreen and enable the PVR's bilinear filtering, the image looks very nice and it's fast. It really doesn't matter what resolution I run at. The DC's PVR stretches the texture nearly instantaneously no matter what. In fact, it's really an easy job for the PVR considering that it only has to draw two textured triangles (I could explain that but I would have to get into stuff that should be in the Programming Forum). And it's capable of 3.5 million polygons/sec.
There's one slow thing involving the graphics that simply can't be avoided, and that's updating the video memory with the new frame. The data transfer between the SH4 and the PVR memory is not as fast as SH4 and it's own memory. But if you want to see your game, it has to be done.

Great deal of speed? Well, so far, different games run at different speeds. The slowest I've seen is 5 fps and the fastest is around 40 fps. One game I like testing is Street Fighter II: The World Warriors because it performs nicely and is very playable.

As for sound, I worked on that tonight but still haven't got it working yet. It's pretty complicated. I envision that you, the user, will be able to change the sound rate and disable it altogether. I just have to figure out how to enable it first!

You've probably already thought of this, and there's probably something wrong with it, but there are tools on the net that will extract images from a ROM. How about extracting them on startup into the PVR RAM? That way the graphics are loaded already, and I'm pretty sure that there's enough RAM to handle it. The pointers might get messy though.

Just a thought.

[BlackAura]

Storing the graphics in video RAM has been thought of for a Genesis. The problem is that you'd have to try to get the PowerVR hardware to do all the rendering by itself, not just displaying an image rendered by the CPU. That might be possible on the Genesis, but for the SNES it would be an absolute nightmare.

[Ender]

Rendered? So you can't just pull out the images as images, toss them on a poly and dump them on the screen?

[sheng]

A BMP vertion is at work.

[sheng]

one of biggist problem with DreamSNES I have was auto restarting. I have a MP3 file that seems to restarts the console after mid way through

[Strapping Scherzo]

Yes, you can get out tile and sprite data out of ROMs using various tools, but it takes human analysis in order to figure out what blocks of images data make up an entire sprite for instance. Have you ever used one of those ROM hackers/editors? You have to scan past a whole bunch of garbage (probably actual executable code) before you find something that resembles mario, for example.

I think the best one could do is monitor the sprite and tile memory of the emu, and when it makes writes to it, update a texture in the PVR that is that sprite, then correctly render that later on on top of and behind the right background layers. I'm sure you'll all agree that you'll end up writing a lot more to video than you would have before and you're doing it little by little. There's an advantage of writing a whole bunch of memory at once. It's fast. And that's how it's being done right now. the snes9x code emulates to a buffer that is in main memory, and when the time is right it's blasted to video memory. The places I will have to concentrate on are expensive looping. And nothing is more expensive that the CPU emu loop.

Yes, SNES CPU was somewhere just around 3Mhz. But think about that. 3 million times a second the DC have to duplicate what the SNES would have done. And why is that so hard? For one thing, the SNES's CPU registers are now represented as data in the DC's memory! So if the SNES wanted to increment a register which takes, let's say around 3 clock cycles... what the DC now has to do is read the "register's" value from memory into its own register, then increment it, then put the new value back. This whole thing now took maybe 3 or four times what it would have taken the SNES. And that's probably one of the simplest examples there is.

Oh, and if you are all wondering why I'm write such long posts and not coding... I'm tired. Brain is fried.

[sheng]

poor scherzo

[Mikey242]

Well heres a pic of my new title screen.

I like all the other pics posted, some great ideas comming out.
Sounds quite tuff scherzo, i understand now why making this emulator is very difficult.

I like your side menu sheng, looks great, esp the selection border.



The version number in th corner is for the emulator cuz i imagine there will be quite a few versions.

Also do you think the snes controller is a bit too small? I could easily make it bigger if it is.

[sheng]

Very nice

[toastman]

Yes, you can get out tile and sprite data out of ROMs using various tools, but it takes human analysis in order to figure out what blocks of images data make up an entire sprite for instance. Have you ever used one of those ROM hackers/editors? You have to scan past a whole bunch of garbage (probably actual executable code) before you find something that resembles mario, for example.

I think the best one could do is monitor the sprite and tile memory of the emu, and when it makes writes to it, update a texture in the PVR that is that sprite, then correctly render that later on on top of and behind the right background layers. I'm sure you'll all agree that you'll end up writing a lot more to video than you would have before and you're doing it little by little. There's an advantage of writing a whole bunch of memory at once. It's fast. And that's how it's being done right now. the snes9x code emulates to a buffer that is in main memory, and when the time is right it's blasted to video memory. The places I will have to concentrate on are expensive looping. And nothing is more expensive that the CPU emu loop.

Yes, SNES CPU was somewhere just around 3Mhz. But think about that. 3 million times a second the DC have to duplicate what the SNES would have done. And why is that so hard? For one thing, the SNES's CPU registers are now represented as data in the DC's memory! So if the SNES wanted to increment a register which takes, let's say around 3 clock cycles... what the DC now has to do is read the "register's" value from memory into its own register, then increment it, then put the new value back. This whole thing now took maybe 3 or four times what it would have taken the SNES. And that's probably one of the simplest examples there is.

Oh, and if you are all wondering why I'm write such long posts and not coding... I'm tired. Brain is fried.

Couldn't you use the register keyword to have those specific variable stored in registers? (I do not know if gcc for the SH4 actually supports this or the results of said operation, so heed my advice at your own risk)
Also, if you did blit the tiles and sprites as they were drawn, into individual textures, couldn't you also store the beginning address of that sprite/tile, so that the next time the ROM called for it, you could instead reference it from PVR memory instead of regrabbing and reblitting it?

Warning: crappy pseudo-code coming. It outlines pretty much what I'm thinking of though.

Code: Select all

 struct sprite_mem
 {
  pvr_texture_t * sprite;
  uint16 location;
 } sprite_bank[50];
 int si = 0; //sprite index

 //Later on
 if (! in_bank(mem_addr))
 {
  sprite_bank[si].sprite = grab_sprite(mem_addr);
  sprite_bank[si].location = mem_addr;
  si++;
 }
 draw_sprite(mem_addr);
 

[Strapping Scherzo]

Couldn't you use the register keyword to have those specific variable stored in registers? (I do not know if gcc for the SH4 actually supports this or the results of said operation, so heed my advice at your own risk)

Yes, For the past day I've been thinking of doing that. I've been thinking that maybe I can just write smarter C that use the register keyword and calls almost no functions in the cpu execute loop; get register values at the beginning of the loop and write 'em back at the end and use macros for the opcodes and such all in between. It would be nice to avoid writing assembler if I can help it. Also, as the code is right now, if I get the intermediate assembler that GCC generates from the C source during compilation, it's a 17,000 line nightmare! I thought I could optimize this generated asm but I'd rather write it from scratch if I have to. But, if I write a single large function that does everything, then I might get something that is easier for an asm amatuer like myself. We'll see if GCC honors the register keyword when compiling for SH4.

As for the graphics, I might consider trying something like you are proposing if I need to get that extra bit of performance after optimizing the cpu. It just seems like a lot of work for not a guaranteed gain. And I'd really REALLY have to learn how the emu works in order to accomplish it, which all in all wouldn't be a bad thing. But I can treat the optimization of the CPU code almost like a black box. It's like something has to get from point A to point B and I just have to figure out the quickest route.

[Mikey242]

Hey i have a question. I was thinking of buying a new dc (my old one is at home in another country and my brother uses it), but i heard the newer ones were designed not to be able to read cdr's hence homebrew, is this true?

[Quzar]

mickey, through testing that has been disproven. also, i had an idea for the logo, although it is subtle, why not make the color scheme of the buttons like that of the DC, with red on bottom instead of the way the SNES colored controllers had it? it is only a slight change, but that would make for a DCsnes generic logo since the colors are just rotated clockwise by one button, just a thought.

[multiverse]

mikeys is probably the best!!! its really nice, im going to see if i can come up with something else soon. BTW, I am playing metroid prime right now and I cant wait till this EMU is working at a playable speed for most games because the next game on my list to play is Super Metroid

Oh, and if you are all wondering why I'm write such long posts and not coding... I'm tired. Brain is fried.

take a break whenever you want!! its not like your our programming slave

[Mikey242]

Thanks guys. Im not too sure what you mean quazar thou I have a vague idea (are you suggesting this for a logo or for the order of the buttons in the menu?).

Yes he is our programming slave (whip crack) get back to work lol. J/K dont work too hard, your doing an excellent job already .