Gp2psx V0.34


frameskip 0 = 7 framerate
frameskip 1 = 7 framerate
frameskip 2 = 8 framerate
frameskip 3 = 9 framerate
frameskip 4 = 7 framterate

so i guess FS 3 is best for RE2.
 
Heh...
It's official, I need sleep.
I left out the actual frameskipping process.
That's why I was able to set the frameskip to 100 and not notice anything, and that's why Paradox's frameskip framerates are so close.

So...
*** FRAMESKIP IS NOT WORKING IN V0.34e ***
...hopefully I'll have frameskip working tommorow. Sorry about this.
 
zodttd posted on Feb 4 2006 at 12:54 AM said:
Oh yeah, dual cpu support. It's not happening until I can find a use for it. Dual CPU's seem really helpful in a threaded application, but in an emulator, how can the first CPU "talk" to the second one while still keeping in sync? For instance, I did a dual-cpu blitter. It used the second CPU to do all the routine blitting/drawing to the display of the GP2X. Problem is, if first CPU doesn't wait for the second CPU to be done blitting, then things get all out of sync and graphical and other errors occur. So what's the point of the second CPU if it's a bit slower and the first CPU would have to wait for it anyways? My guess is, I'm not using it effictively. If someone can give me some usable ideas for the second processor, I will try it out.
Any other developers been able to use dual cpu's for an emulator?

I remember hearing that dual CPU use is not handled very well through linux for some reason. You would have to bypass linux to get both CPUs working well together. Squidge knows something about this. He may be able to help.
 
Last edited by a moderator:
My blitter using the second cpu used shared memory to inform when a new frame was needed. But then, and for the exact reason I forgot, I think it needed to be sync'd since the framebuffer can't be read and wrote to at the same time. So in order to prevent that memory issue from happening, it would need to wait for the blit to be done before writing to the buffer. Sounds like you just sync when needed right? Well when you're doing 10+ syncs a second, it really doesnt make it worth it.

Saw this in a seperate thread, could be of benefit to you if it gets implemented

for example we are in discussion with GPH to change the framebuffer MMU configuration to enable "caching", which is disabled by default and unfortunately kills the graphics perfomances of the device...

[topic=25353]Click me![/topic]

Might solve framebuffer/dual Cpu issues

Keep up the good work!

Also when you implement the arm assembly code won't this bypass the linux kernal?

(I'm not a dev just guessing, don't flame me for being dumb)

Oh and maybe this?

I was trying to use gp2x's framebuffer directly - no SDL, just opening the /dev/fb0 device. My first attempt was 7.5MB/s of filling the framebuffer in the C. The second one using the 32 bit integers got better at 21MB/s. The 3rd using the "register" statement for variables got me 42MB/s. That is quite an improvement!

[topic=25425]Click me![/topic]
 
Hopefully we will be able to use the second processor for SOMETHING... maybe you can just have it go sound/graphics frame by frame? Like putting the graphics in 1 processor and have sound be done in the second, but only let sound go if graphics goes...

EDIT: Just thought of it: use it for decompression!
 
New release, v0.34f:
http://www.friggingames.com/gp2psx034f.zip
------------------------------------------------------------------------------
UPDATED February 4th, 2006
New in version v0.34f:
- Dramatic overall speedup over last release (v0.34e). I'm finally able to reach better timings of interupts. FF7 gets 21 FPS without sound, and 17 FPS with sound (tested at the first save point) with 0 frameskip. Not too shabby!
- Frameskip works now. How embarassing, I forgot to include it in the last release. Anyways, use Volume Down/Up to control frameskip. Going from frameskip 0 to frameskip 1 will make the biggest difference. Frameskip 2 will speed things up further, but may make things choppy as well. Frameskip 3 and higher will most likely be very choppy.
---------------------------------------------------------------------------------

If this release goes well, I'll get things ready for v0.35. Sorry for all these minor updates, but one of the reasons is to get ZPSX and my other PSX ports ready and sync'd with GP2PSX's version.

So over the last two releases you get a large speed increase, a working frameskip, and better compatibility. Yay! :)
Hopefully this release will play for you as well as it does for me. :)
If anything, play FF7 with it at 20 FPS. :)

We're a third of a ways there...

Also, thanks for the help with deving. I currently use the Minimal library for GP2PSX, which uses direct access to the framebuffer. I wonder if fb0 is faster than fb1 or vise versa? Sometimes there's a difference in handhelds.
 
good grief zodttd....is this still without the New GPU and the other major alterations going on?
 
wow, really impressive progress :)

tried Civ2 (pal) with 0.34f again, but even @250MHz and fs=1 i have a framerate=2 in the game setup menu.
it takes almost 10 minutes to get into the game.
the ingame is as slow as the intro (frameskip=1 framerate=2) but the music is even slower as normal. the setup music was in correct speed.

hm, i can't figure out how a game like FF7 can get framerates above 10, but a 2D game like Civ2 cant get over 2 or 3.
 
0-bake posted on Feb 4 2006 at 02:11 PM said:
wow, really impressive progress :)

tried Civ2 (pal) with 0.34f again, but even @250MHz and fs=1 i have a framerate=2 in the game setup menu.
it takes almost 10 minutes to get into the game.
the ingame is as slow as the intro (frameskip=1 framerate=2) but the music is even slower as normal. the setup music was in correct speed.

hm, i can't figure out how a game like FF7 can get framerates above 10, but a 2D game like Civ2 cant get over 2 or 3.

Not that much motion probably. The backrounds are just pictures (sometimes animated), and there is very little 3D (minus battles).
 
Last edited by a moderator:
The hardware of the PSone hardware was made for 3d games and always struggled with 2d games, while the saturn hardware was the opposite.

P.S Shikaku glad to see you didn't orgasm....you were making the forum very messy!
 
mattyrb posted on Feb 4 2006 at 02:13 PM said:
The hardware of the PSone hardware was made for 3d games and always struggled with 2d games, while the saturn hardware was the opposite.

P.S Shikaku glad to see you didn't orgasm....you were making the forum very messy!

I did.... and I also (really) screamed when I saw 21 FPS. I just died orgasming =p
 
Last edited by a moderator:
DaveC: Your thumbpad looks awesome! I'll see if Squidge (yoda of GP2X) knows of anyways to help the project out.

Civ2 is a game that has a lot of static images, so it might be going at a higher framerate, just that the frames aren't being counted since they haven't changed each frame. But Civ2 is a hard one to get up to speed. Try turning off sound, it will help. I don't know exactly why their "effects" in their menu'ing system go so slow. The game loves to waste cpu cycles. Once it's in game does it go at good speed visually (nevermind the framerate counter)? Also, generating the map will take a bit sometimes.

Any other games tested yet? :)
 
pantera6 posted on Feb 4 2006 at 07:19 PM said:
i got a few PS1 games, anyway i can put them on my gp2x?
Yes you can read back in the topic.....I'm sure this was discussed donkeys ago :)
 
Last edited by a moderator:
Nice update zodttd. Most games are nearing playable which is great, but Ace Combat 2 still doesnt run too bad :p
 
Back
Top