Dynarec Completed For Psx4all Project.


zodttd posted on Sep 29 2006 at 09:09 AM said:
The ARM920T has a Vector Floating Point Unit (VFPU) alongside the standard FPU instruction set. The GTE is a bunch of vector math ops, and with Tinnus' help the ARM's VFPU is almost done in the GTE.

It should reduce some GTE ops from 100+ cycles to 16 or so. :)

Could you explain the VFPU a little better if possible. Since the GP2X doesn't have a FPU, is this like a arm based software component that improves FPU requests?
 
Last edited by a moderator:
Oh, maybe Tinnus has me confused, but it seems like by using a combination of the MUL and MLA instructions you can load matrix's and do the math needed by the GTE. I had assumed instructions such as MLA were part of a VFPU, and that the 920T supported it from reading the documentation I have. But as I said, I may be confused somewhere along the line. :p
 
Great news, glad you are still making progress! Most important thing to me is speed, then sound. As long as I can save to memcard... that's enough! :)

Also what happened to that idea of scaling up the interlaced screen? I guess it's not as important any more, but I still liked the idea behind that.
 
Oh great one:

I'd have to vote for memory card support over savestates, but that may be because I play a lot of games where it comes into play more than just continuing where you left off(ChronoCross and other games with NewGame+ or similar options).
 
Yes, I'd definitely prefer standard memory card support. Don't include save states as I'd feel the need to cheat.
 
I quite liked sound in the older ones and some games it didnt make much difference to the speed.

Im still tryin to get a v43 but its startin to seem impossible can i not just buy your one ? :p
 
my wishes are about Oddworld looking good :D
Zodd please deliver us from our suffering... tell us when you plan to release your top secret emulator that runs Ridge Racer @ 20fps :p
 
reiboul posted on Sep 28 2006 at 09:50 PM said:
Unfortunately for PSP owners, they will have to pay for play, as usual ;)

Not always ;)...
 
Last edited by a moderator:
I vote for speed first :)
How does ff7 perform on the new emulator?
sound would be very cool too, but if slows down stuff it should be able to turn off :)
 
save states can wait, they are not needed *At all* as long as memory card saving still works fine, dont bother wasting time on save states when the speed of games isnt good enough to warrant playing the game anyway to use save states... if anything more important than speed has to be sound quality, then perhaps a more usable GUI with options like FPS etc. sounds like its making progress and getting polished up...
 
Steve-O posted on Sep 29 2006 at 06:14 PM said:
reiboul posted on Sep 28 2006 at 09:50 PM said:
Unfortunately for PSP owners, they will have to pay for play, as usual ;)

Not always ;)...


pay, or use illegal softs ;)
 
Last edited by a moderator:
huh? i thought the psp psx emu was much like this project... 'home grown' ?

How is that illegal?
 
Paradox posted on Sep 29 2006 at 06:02 PM said:
save states can wait, they are not needed *At all* as long as memory card saving still works fine...
Agreed.

I can't say I understand the framerate terms used.. when I wrote games, they ran at N frames per second - eg 50/60 or 25/30 (vsynced) etc..

I guess this is how you term 'unique' frames? Surely this is the framerate that's important - frames per second of frames that haven't changed isn't an issue..? It could run at 1 or 100 fps and we wouldn't know the difference?

Maybe I'm confused.
Good work zodttd, even if I don't understand! ;)

Kev
 
Last edited by a moderator:
i think he is using it to find out how many cycles and therefore possible frames that cud be rendered per second but the unique is the frames that are actually different and therefore is the true fps as in what we would recognise as a flip in animation.

Probably doesn't display these same frames to save cpu cycles, possible judge how the rest of his code effects the programs ability to render a new screen per second and therefore the emus max fps if the emulation can achieve this roof fps????

I may be way off but thats what i got from the posts

EDIT: sorry for my messy explanation, mite be correct mebe possibly?
 
^RaZ posted on Sep 29 2006 at 02:25 PM said:
i think he is using it to find out how many cycles and therefore possible frames that cud be rendered per second but the unique is the frames that are actually different and therefore is the true fps as in what we would recognise as a flip in animation.

Probably doesn't display these same frames to save cpu cycles, possible judge how the rest of his code effects the programs ability to render a new screen per secondand therefore the emus max fps????

I may be way off but thats what i got from the posts

Basically in boolean logic:

1 IF the screen has changed
2 change screen
3 calculate next screen
4 GOTO 01
 
Last edited by a moderator:
Yeah thats what i meant to say!

But if it also runs past the 'draw frame' code more often than required it is also an indication on the potential fps of the app, since there are n times the frame is not different. If the emulation becomes more efficient then the n will fall, but the addition of n and frames rendered = the max fps attainable, an indication of how effecient the update render cycle is?

I'm not a game programmer was just trying to help, this is just my understanding. Cue talented dev :-
 
^RaZ posted on Sep 29 2006 at 06:57 PM said:
huh? i thought the psp psx emu was much like this project... 'home grown' ?

How is that illegal?

Their is a Homebrew PSX Emu for the PSP but Sony is also releasing an official PSX Emu type thing running at full speed with sound... Only problem with the Sony one is they are going to charge you to download the PSX Games to run on it but seen as I already Own the PSX games legally that I want to play I dont see why I should have to re buy the game ;)

anyway, keep up the good work on the GP2x PSX Emu, might buy a GP2x just to try it out :)
 
Last edited by a moderator:
psx4all is using an optimization in the GPU to tell if the frame has changed from the last one or as some say, check if the frame is "dirty"...

Imagine the PSX displays an image without changing it for an entire second.
The VSync interrupt will be 60 (if performance allows for it), and in psx4all it will show "1" for Framerate.

Now which number do you use for the framerate, the 60 or the 1? We've been going by the "unique frames" as I call it, which is 1.

So Framerate isn't currently on a scale of (really slow) 0-60 (fullspeed). Thats because it's only telling you how many frames were drawn to the screen due to being changed since the last draw to screen.

On the beta's released recently the VSync rate can't be trusted as underclocking affected that rate.

We're working on getting a better way of showing you the actual framerate of psx4all, but it's tricky for the reasons explained above.
 
for knowing the real speed: disable all frameskip etc, and manually measure the speeds of ingame chronometers :D (1 game seconds=2 real seconds: 50% speed, 30fps, easy, the more game seconds you count the more precise you are :) )

then you know exactly how slow it is without affecting the performance with FPS counters :D
 
hmm how feasible would it be to make an intelligent frameskip that starts to skip frames who are not "unique" ?

example

no skip Frame 1 ###########

no skip Frame 2 ###########

skip this Frame 3 ###########

no skip Frame 4 ######___###
 
Back
Top