SNES emu in the works
-
- DC Developer
- Posts: 2285
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Fri Feb 21, 2003 7:37 am
- Location: Chicago, IL
- Has thanked: 0
- Been thanked: 1 time
- Contact:
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 ?
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 ?
-
- DC Developer
- Posts: 2285
- Joined: Fri Feb 21, 2003 7:37 am
- Location: Chicago, IL
- Has thanked: 0
- Been thanked: 1 time
- Contact:
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!![Surprised :o](./images/smilies/icon_eek.gif)
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!
![Surprised :o](./images/smilies/icon_eek.gif)
![Image](http://img159.imageshack.us/img159/5720/pub9.4651202415174E+27.png)
Wow it's really good!mastakilla wrote: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
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Dream on
- Ender
- DCEmu Super Poster
- Posts: 1314
- Joined: Mon Dec 10, 2001 4:01 pm
- Location: Canada, first igloo on your left.
- Has thanked: 0
- Been thanked: 0
- Contact:
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.scherzo wrote: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!
Just a thought.
-
- DC Developer
- Posts: 9951
- Joined: Sun Dec 30, 2001 9:02 am
- Has thanked: 0
- Been thanked: 1 time
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.
-
- DC Developer
- Posts: 2285
- Joined: Fri Feb 21, 2003 7:37 am
- Location: Chicago, IL
- Has thanked: 0
- Been thanked: 1 time
- Contact:
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.
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.
![Image](http://img159.imageshack.us/img159/5720/pub9.4651202415174E+27.png)
-
- DCEmu Veteran
- Posts: 412
- Joined: Tue Jan 22, 2002 4:43 pm
- Location: Newcastle, U.K. (Born: Bahamas)
- Has thanked: 0
- Been thanked: 0
New screen
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.
![Image](http://groups.msn.com/_Secure/0QgDiAuQS6GbwU5m8N1llQB62JiqZjtlKU3Sf7JK3BAH!z*sNg5lGXiuZqeEnRFVKzbIC4kQzmsce54s!LKFNVOwGAeMw59ZEnmU*7!JdurM/Menu1-4.jpg?dc=4675455639859867301)
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.
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.
![Image](http://groups.msn.com/_Secure/0QgDiAuQS6GbwU5m8N1llQB62JiqZjtlKU3Sf7JK3BAH!z*sNg5lGXiuZqeEnRFVKzbIC4kQzmsce54s!LKFNVOwGAeMw59ZEnmU*7!JdurM/Menu1-4.jpg?dc=4675455639859867301)
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.
- toastman
- Iron Fist of Justice
- Posts: 4933
- Joined: Sat Nov 10, 2001 3:08 am
- Location: New Orleans
- Has thanked: 0
- Been thanked: 0
- Contact:
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)scherzo wrote: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.
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);
No signature.
-
- DC Developer
- Posts: 2285
- Joined: Fri Feb 21, 2003 7:37 am
- Location: Chicago, IL
- Has thanked: 0
- Been thanked: 1 time
- Contact:
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.toastman wrote: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)
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.
![Image](http://img159.imageshack.us/img159/5720/pub9.4651202415174E+27.png)
- Quzar
- Dream Coder
- Posts: 7499
- Joined: Wed Jul 31, 2002 12:14 am
- Location: Miami, FL
- Has thanked: 4 times
- Been thanked: 10 times
- Contact:
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.
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man
-
- Insane DCEmu
- Posts: 102
- Joined: Sun Oct 12, 2003 10:31 am
- Has thanked: 0
- Been thanked: 0
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 ![Smile :)](./images/smilies/icon_e_smile.gif)
![Razz :P](./images/smilies/icon_razz.gif)
![Smile :)](./images/smilies/icon_e_smile.gif)
take a break whenever you want!! its not like your our programming slavescherzo wrote: Oh, and if you are all wondering why I'm write such long posts and not coding... I'm tired. Brain is fried.
![Razz :P](./images/smilies/icon_razz.gif)