Monday, June 26, 2006

Deciding what to optimise

Whenever I start to answer questions on the comment pages I always end up going into too much detail for a quick response and end up deciding to put up a new post instead. I hope this isn't too annoying :)

In response to Plans for R6 xiringu and ukcuf16 had a couple of interesting suggestions for performance improvements.

First up, from xiringu:

instead of working with a 300x200 screen, work with only half height 150x200 and then display an empty line every other line to get the final 300x200.


That's an interesting idea - it's a trick that's been used by demo coders for years to get a few extra fps. I'm not sure this is going to provide all that much of a speedup to Daedalus though :( The reason for this is that currently rendering only contributes a small amount to the overall cost of each frame, so even if rendering time was totally eliminated, the framerate wouldn't change much. As an example, let's take something like Zelda which currently runs at around 4 fps. At 4fps it means each frame takes 1000/4 = 250 milliseconds to render each frame, which is broken down something like this:

CPU emulation: 200 ms
Display list parsing: 40 ms
Rendering: 10 ms
Total: 200 + 40 + 10 = 250 ms (i.e. 1000/250 = 4fps)

Assuming that we could totally eliminate the rendering time, this would now look like:

CPU emulation: 200 ms
Display list parsing: 40 ms
Rendering: 0 ms (no cost)
Total: 200 + 40 = 240 ms (i.e. 1000/240 = 4.17fps)

So the very best we could hope for in this case would be a .17fps improvement in the framerate :(

ukcuf16 wrote:

Just wanted to ask if there is ever going to be frame skip in later versions :)


What ukcuf16 is suggesting is that the emulator renders one frame, then skips the next. Alternating frames like this should halve the cost of rendering, at the cost of making the framerate a little less smooth.

Again, this is an interesting idea, but I don't really see this having much impact on the framerate as things stand at the moment. Working out the potential speedup is a little more complicated, as we have to take the average time over two frames. The numbers look something like this:

Frame1 CPU emulation: 200 ms
Frame1 Display list parsing: 40 ms
Frame1 Rendering: 10 ms
Frame2 CPU emulation: 200 ms
Frame2 Display list parsing: 0 ms (skipped)
Frame2 Rendering: 0 ms (skipped)
Total: 200 + 40 + 10 + 200 = 450 ms
Average: 450 / 2 = 225 ms (i.e. 1000/225 = 4.44fps)

So even implementing a frame skip mechanism would only give a tiny 0.5fps speedup.

To take this example to its ultimate conclusion, let's assume that I could somehow eliminate the entire cost of display list parsing and rendering:

CPU emulation: 200 ms
Display list parsing: 0 ms (no cost)
Rendering: 0 ms (no cost)
Total: 200 ms (i.e. 1000/200 = 5fps)

Even if I could somehow (magically) reduce the cost of rendering to 0 milliseconds, we'd still only see a 1fps speedup. However, if I can halve the cost of CPU emulation (which is much more likely given the speedups already seen with the new dynarec engine) this is what the calculations look like:

CPU emulation: 100 ms (now twice as fast)
Display list parsing: 40 ms
Rendering: 10 ms
Total: 100 + 40 + 10 = 150 ms (i.e. 1000/150 = 6.66fps)

At the moment I feel that there are more gains to come from optimising the CPU emulation, which is why I've been concentrating on this area recently. As the cost of CPU emulation falls relative to rendering then the ideas suggested by xiringu and ukcug16 will start to become more attractive.

-StrmnNrmn

73 comments:

tsurumaru said...

Hmm an interesting read as normal, thanks Strmnnrmn. Good luck with the R6 work! :)

Morgan said...

Strmnnrmn we don't get annoyed by these updates actually we look forward to them. It's nice to read something new about the progress, keep it up! I don't know anything about coding so, but yeah what is the next big thing you could do to help the speed and smoothness increase. Lastly in the comments on the last update PSDonkey said he made some changes to the R5 source AGAIN* and uploaded them and emailed it to you, are his changes anything to help out the progress? And if possible could you provide a link to compiled source he made?

VorTeX Raptor said...
This comment has been removed by a blog administrator.
VorTeX Raptor said...

Nice explanation, its good to see that you are working hard at the emulator, i just wanna say thanks and keep up the good work =]

Andrew N said...

Hey StrmnNrmn
First off I think your emulator is a big contributor to the growth of the psp homebrew scene. It is also my favorite emulator because of its great potential.

Though legend of Zelda is not nearly as fast (fps wise) as a game such as Mario 64, which for me runs at an average of 10 fps in the castle. So if the fps breaks down the same way as in legend of Zelda then it would be something like
100 ms to render each frame.
Cpu emulation = 80 ms
Display list parsing = 16 ms
Rendering= 4 ms
80 +16 +4 = 1000/100 = 10 fps
Though I doubt that the CPU, display list parsing and rendering affect on fps are the same in legend of Zelda and Mario so I am most likely wrong

So if you were to implement frame skip it would come out to something like this
Frame 1 CPU emulation = 80 ms
Frame 1 display list parsing= 16 ms
Frame 1 rendering = 4 ms
Frame 2 CPU emulation =80 ms
Frame 2 display list parsing = 0 ms (skipped
Frame 2 rendering = 0 ms (skipped
Total 80 + 80 +16+4 = 180 ms
Average 180 ms /2 = 90 ms (i.e. 1000/90 ms 11.111 fps

1.11 is still not a lot (same percentage as loz) . But lets say you half the cost of CPU emulation to 40 ms (thanks to a compete dynarec engine) and implemented a frame skip. Lets have it skip 2 this time. So there for it would go frame. Skip. Skip. Frame. Skip. Skip
F = frame
F1 CPU emulation =40 ms half as fast
F1 display list parsing = 16
F1 rendering = 4
F2 CPU emulation = 40 ms
F2 display list parsing = 0 skipped
F2 rendering = 0 skipped
F3 CPU emulation = 40 ms
F3 display list parsing= 0 skipped
F3 rendering = 0 skipped
Total= 40+40+40+16+4= 180 ms
180/3= 60 ms 1000/60 = 16.666 fps

My point :), you are right in not implementing frame skip yet but I think in the near future Like after you finish your dynarec engine for a notable speed boost.
This post is pretty redundant because you stated this in a nutshell in you last paragraph but 16 fps Mario sounds so sweet. :)
Even if it is choppy.

Morgan said...

I want it smooth so I wouldn't like it for right now. I just want Stmnnrmn to speed it up in the best ways he knows how, so that it runs great.

PSmonkey said...

(psmonkey here. some bastard took psmonkey sadly).

Strmn, You don't go on msn anymore. :(

Anyways any plans to strip the core instruction set to pure 32bit? I am currently in the process of doing this and it gives a considerable boost not handling 64bit registers (yet still using the full 64bit register on 64bit instructions like DADD).

Since the entire psp pipeline is 32bit, any 64bit values will bottleneck it all (actualy also looking into stripping the double floating point precission instructions).

Morgan said...

Psmonkey good to see your working on your emulator! Do have a release maybe in the future? If so when maybe? How far along is the emulation comming? Like how fast is it running games?

Laxer3A said...

Hi,

1/ Definitely that render odd or even line is actually more difficult considering the fact that you probably translate your graphic call from the N64 in native graphic PSPGU calls.

2/Your benchmarking definitely shows that the dynarec is going to be the key of performance improvement in your emu. and is a MUST as I said before.

Now it start to be very clear that you need it to be REALLY smart from now to get good speed improvement.
To get all the potential out of the dynarec you will need to analyze completly the generate chunk. and optimize it globally also. (useless moves, better use of the delay slot, avoid useless pipeline flush may be ?).

When I see that I am not sure that you should generate directly ASM instruction into the chunk while decoding the N64 code but really rely on a "intermediate" encoding allow to build tree of operations, detect register usage and so on...
And then generate your PSP code at the end, once a chunk has been parsed and optimized.

Anyway, just throwing out ideas, as usual, coz I dont have so much time to look at the source in details.

Regards.

PSPUMD said...

Hi There: I just wanted to say a BIG THANK YOU for this , it must have been hard process to even get this thing to run since R1, you have made some AMAZING progress on this project and i totally appreicated. Thank you and keep up the goods. YES, a cpu to 100 definitely sounds good ^^

frmariam said...

Well regardless of any other improvement I really hope you can fix the cause of freezing in 2.0 tiff... Nowadays seems that tiff is always a problem...

R4 froze like less than 10 minutes after starting Mario 64 and R5 freezes before I even enter the castle...

I'd love to pass Mario64 all over again in the PSP... And Mario Kart 64...

I can tell this is a really though job and that you put a lot of hard work into it.

If you ever try to tackle the gameplay time crashes in 2.0 tiff and need anyone to report on it mail it to me at sousa.jff@gmail.com (sorry I bet you are tired of ppl begging to beta but it's just that so many new apps work in GTA and not in tiff... like all GBA emus apart from PSPGBA 1.0 by psp298)

Morgan said...

Hey why don't you downgrade to 1.5 and use devhook? I was a 2.0 user because I loved GTA but then when devhook came out I said I'll test it out. I love 1.5 because I know I get the fastest and best homebrew and I can play any UMD up to 2.5! I'm staying where I'm at forever now and I can't wait till Devhook is up to 2.7 and it looks like that could be very soon!

Ps. Strmnnrmn please gives us a link to the changes donkey made and sent to you on the R5. The changes he said in the last update in the comments! You have a link to a compiled source code?!

Exophase said...

One thing I've been wondering. What's the native N64 frame speed supposed to be for Zelda 64? Is it 16.7ms (60FPS) or 33.3ms (30FPS)? Or something else altogether...

wally*won_kenobie said...

zelda runs at 60fps natively.

waves to PSmonkey :)

Morgan said...

Strmnnrmn please answer my question!

ukcuf16 said...

^^^^ stop bein impatient .. GOSH

PSdonkey said...

Yes, Morgan. Norman is very busy right now. For those of you who want the updated changes to the source, here are the links to the 1.0 and 1.5 binaries. I already sent the source to norman so anyone who wants to take a look at the source feel free to either email norman or myself for the updated source code and one of us will send you the source.
Basically this new R5 edition has the new eboot icons and sound from before and also the new menu backgrounds from before as well. The newer code that was implemented is the addition of menu music while you are browsing through the options and rom list. As soon as you choose a rom to load, the music stops and clears the memory for the use of loading the rom into the memory. You can also create your own custom mp3 music for the menu and putting it inside your Daedalus folder naming your mp3 "menu.mp3" It doesn't really matter how long your music is because once it finishes, the music will repeat itself until you choose a rom to play then the music will be freed from the memory usage so that the emualtor will still have all the necessary memory that it needs. Also, once again, this new R5 update has the rom folder the same as the folder that Monkey64 uses. You need to place all your rom files in the root of the memory stick called "n64" just like the way Monkey64 does. So there is no more "Rom" folder in Daedalus. I am working on a few more additions to Daedalus for when R6 comes out. Once again to make things clear, All 100% credit goes to StrmnNrmn for this awesome work of his. Anyone else who has some new ideas for StrmnNrmn's future releases, just drop him an email with the updated source and i am sure he will incorporate it into the new release. Here are the binary files cut in half so that you can see the whole link. Just copy and paste the top part and the bottem part of the link into your browser.

Link for R5 Changes for 1.00

http://rapidshare.de/files/24398732/
Daedalus_100_R5_New.rar.html

Link for R5 Changes for 1.50

http://rapidshare.de/files/24398995/
Daedalus_150_R5_New.rar.html

Here are the full links if you can view them

http://rapidshare.de/files/24398732/Daedalus_100_R5_New.rar.html

http://rapidshare.de/files/24398995/Daedalus_150_R5_New.rar.html

ukcuf16 said...

Thanx u's

kaiser said...

Thanks psdonkey!
I love the new changes!

Morgan said...

PSDonkey thanks for providing the links I'm going to test them out now! But yeah thanks for dedicating your time to this emulator. But really if you have a working N64 emulator why not release it? Or couldn't you at least give Norman some serious help on getting his very fast? Either way thanks and sorry for getting a little impatient, StrmnNrmn keep up the great work!

ukcuf16 said...

why is some kid posing as Kaiser?

bstickq said...

It's pretty obvious that kaiser, morgan, and kersplatty are just three of psdonkey's many aliases. After constantly harassing psmonkey for weeks I'm surprised anyone would give this ***hole the time of day. Anyways, sorry for being off topic, I can't wait for your next release StrmnNrmn!

Kaiser said...
This comment has been removed by a blog administrator.
Kaiser said...

I don't who is posing as me but its pissing me off. Reminds me of those suspicous accounts we were getting at DCemu. Those accounts would constantly pop up only to bring up Donkey and to be subsequently banned by my self.

Perhaps Donkey is turning a new leaf, but until I see some solid proof (an altered src) I'm not going to change my opinion on this guy. So far we've only seen compiled PBP's with added icons or music.

I think Donkey is using my name to gain public support by making it seem DCemu is behind him. I suggest a major cleanup of these blogs Strmnnrmn. Its starting to smell of to much Donkeys shit.

PSdonkey said...

I don't come in here as other alias as someone said nor have I EVER went to dcemu under any other name that was not mine. You can goto psp-hacks.com and see that the person named kersplatty is someone from over there and not some made up name.It's sad that if someone says thank you to someone for doing something, they are automatically branded as someone coming in under different names. This is the reason why I stay away from dcemu.com and just post updates and C++ tutorials and lessons over at psp-hacks.com

Now to clear something up.

I never said I had a full speed working emulator. Yes the fps were pretty high, but all games would crash within a few minutes of playing and I still haven't overcome that problem. I had mentioned that months ago. The few people that do have it, tell me that games get worse and worse everytime they play it. I know its some kind of memory problem but I have put the whole project on hold now. Looking at StrmnNrmn's source, I can see that he is getting along alot farther with every build. His source is alot more organized and soildly built also. His dynamic recompiler is alot different than what I had expected as well. In his next release, I'm going to take a deeper look into the core of his source and in his DynaRec and see if I can improve the over all speed of the emulator by adding my own code or changing his code a bit. Other then that, something that people need to know is that not all emualtors are coded the same way. They can actually be very different in code and in approach. You can't just transfer one part of a code of one emualtor into another and expect anything to happen.

bstickq said...

Uhh... by use of an ip check on psmonkey's forum it was proven that you were the user Gaydar, spamming the place up and spreading psdonkey propaganda.

Kaiser said...

As well as other accounts on a multitude of IPs.

Chrisfile, PSPuser10, coors88, Bigboy14, coors888, Iwin, pigtails_19 and a billion variations of the Words "Donkey" and "PS".

Its funny all these accounts you claim have nothing to do with you use the same technique of signing up with a new IP address and posting just like you or even sharing an IP with your PSDonkey, PSD0nKey or PSPDonkey64 accounts.

I wonder if Strmnnrmn can check the IP's of those who post on his blog?

Its no longer considered a coincidence my friend. ;)

Your going to have to do a lot to dig yourself out of the reputation you created.

Kaiser said...

P.S: PSmonkey can back up my accusations, he was present through the whole debacle and can double check all the IP's. Its easy to see how they link up especially after viewing their posts.

LaMa said...

Guys, would you please drop this Donkey debate already. Dont let this ruin StrmnNrmn's nice dev blog.
Take this shit elsewhere, to whatever PSP forums you frequent.

Why do you think StrmnNrmn closed the comments on the previous news update?

StrmnNrmn:
"I'm closing comments on this post now, as I'd rather the PSdonkey debate didn't ramble on forever. Cheers!"

Drop it please.
Thank you.

Morgan said...

I'm sorry guys I think I brought the Donkey issue back up with asking for his changes, I just got excited. But yeah let's not talk about it anymore guys it's leading no where.

PSmonkey said...

Guys, Can we please just let it go.

I got it the worse out of everybody and i'm willing to let it go. It's just dragging into an anoyance.

If donkey never releases his emu, thats just fine. You still all have M64 & Daedalus.

Donkey,

My recomendation, Is never let you're brother have anything to do with your work again. No matter how much you do good and proove your self, you're brother has pernamently tarnished your image in the scene. :(

PSmonkey said...
This comment has been removed by a blog administrator.
FlyingBuzz said...

Not sure is this is possible for psp but maybe you should try writing some simple functions into assembly.

Sometimes a compiler does everything a standard way and does not optomize the machine language output to the best possible.

Just a thought in saving some few ms.

PSdonkey said...

Yes PSmonkey, you are right. I know my brother has caused alot of drama over at dcemu.com and I have apoligized several times already for his actions. However, I have never ever went to dcemu.com under any different names as "kaiser" has suggested. I was never anybody named gaydar or coors or bigboy or pspuser or any other name that "kaiser" is making up. In fact I have seen over there that anybody who has said that I have released something new or done an update to anything, "kaiser" automatically tells everyone that that person is me and then he bans them on the spot. I have also seen "kaiser" ban anyone who even says thank you to me over at that website either. "kaiser" ovbiously abuses his power over there and needs to grow up.
On another note, how can there be 2 "kaiser" here posting with the same name? There can't be. If this person really is the kaiser over at dcemu.com, then he is playing some sick joke/game to everyone. There can only be one kaiser and one password and if this kaiser is the one from dcemu like he says he is then he is just spamming this blog and playing a joke on everyone. Once again, he needs to grow up.
On a finally note, This is StrmnNrmn's blog. Please keep all comments on here regarding his work. If anyone is interested in what I am doing that is NOT related to StrmnNrmn's emualtor, you can either send me a PM at psp-hacks.com or a personaly email if you wish. Quite frankly, it is simply rude to talk about other things on someone's blog that is not related to the blog's sunject.

Kaiser said...

Yes I was abusing my power Donkey and your completely right. :rollseyes: I was not the only one to ban you. Most of the staff and even PSmonkey has banned you on occasion. Some one is using the same screen name as me Donkey. Check the profiles of each Kaiser and you'll see they are two seperate accounts.

Thats my last comment on that issue, PSmonkey is right.

Keep up the good work Strmnnrmn!

Kaiser said...

I had good intentions Strmnnrmn, sorry if I acted rudely by bringing up this old topic.

Sroon said...

Hey StrmnNrmn! Thank you for all your hard work! it is really apreceated!
oh.. and if there was a frame skip option, wouldn't it make the game more leggy than playable? its like when you play Snes emu or what ever, when you put frame skip on it would "basicly" skip frames of the game and make it not as good to play, or is that just with (non) 3D Emu's
Thanks!

bstickq said...

I'm sorry for being off topic too, I've been lurking this and various other forums for awhile and he just got under my skin. It won't happen again.

Back on topic, StrmnNrmn, woudn't frameskip be more useful as the framerate improves?

ukcuf16 said...

^^^yeah he said that in the last paragraph.

bstickq said...

Oh, oops.

kersplatty said...
This comment has been removed by a blog administrator.
kersplatty said...

omfg i dont look in these forums for a few days come back and its a flame fest, i AM NOT donkey i am kersplatty, i am a member of dcemu long before dopnkey ever was, kaiser is a respected member of the dcemu forums and we just want to see a full speed n64 emu for the psp become reality. I support psmonkey as well and just wanted to say thanks so dont even acuse me of being someone im not. anyone in the uk feel free to knock on my door to prove to u im not psdonkey

BTW great work on daedalus hopefully well be able to play on a fast ish emu once england win the world cup :D wooo england play today

cms108 said...

long time no see.

must be about 5 or 6 years now... which is about the length of time it's been since i did any programming... so bear with me if this makes no sense at all... or has all already been implemented.

is there a reason why dynamic recompilation has to be done dynamically?

i understand that you don't know what execution path the code is going to take, so you need to do most stuff dynamically. but there's bound to be blocks of code that can be optimised outside of the emulation itself.

you could have a kind static recompilation. a pre-preocessor that would either create a custom rom for use with the emulator... or maybe generate an intermediate file.. like object code to be used as a kind of patch for the rom. could also perform any texture conversions and any other conversions on other things. that might need... ummm... converting...

anyway... other thing is... doesn't the psp have about 18 processors or something? specifically... doesn't it have 2 x R4000s? could these be used to gether to either run 2 threads simultaneously or perhaps to speed up stuff like 64 bit operations that aren't supported.

also, doesn't the psp have 2 graphics cores, which from what i can tell, seem analagous to the n64's rdp and rsp. i have no idea how they work... but it'd be good if you could offload some of that rsp/rdp stuff to them... but then i spose it'd be good if we had flying cars too.

it's no wonder i got kicked out of 2 universities....

flyinghippo said...

I am very pleased to see how this is progressing further. It is somewhat hard for me to keep up with all this framerate calculating and... er... stuff such as that, as I have never been this far into programming, but just hearing about plans of this project please me. Just because the games do not run at perfect speed yet doesn't mean it will never work, because it is great to know that you are going all the way for this. Good luck with this project, I anticipate seeing more information.

zarquon said...

Any chance that you will now code with the extra kernel functions available to you now on the 2.xx firmware or just code for 1.5 firmware with kernel and media engine access as there is now a full working downgrader for 2.5/2.6 meaning most people will now have a 1.5 available to them

Morgan said...

Looks as if they have Goldeneye, Mario 64, and Zelda running full speed! Check out pspupdates, Strmnnrmn what is your opinion on this? If this thing is true are you going to continue building?

Morgan said...

StrmnNrmn I would also like to see a ME (media engine) version of the emulator. Most psps are 1.5 now so it would make sense to use the Media Engine. I'm sure it would help performance and hey it may open soem doors for you.

Ps. Please answer my question above also when you can, and keep up the great work I know your busy working on it now!

kersplatty said...

that zombi fellas work is good but i will always support strmnrmn and any other coders tbh because of the time and effort involved, besides itll be a while before zombi146 codes a n64 emu for each particular n64 game and some games may not run properly.
KEEP UP THE GOOD WORK!

kekpsp said...

I agree with morgan, you should use the media engine to speed the emulator up now that most people have downgraded, would this constitute a major overhaul of your emulator, could you parhaps code a version with media engine support, and one for user mode, Good luck with your R6 version...

flyinghippo said...

That does seem like a good idea to use the Media Engine, as it might significantly increase the speed. As for that UltraHLE PSP mention, I'm not sure if I should believe it or not. Besides, it highly differs from this emulator, so I would see no reason to discontinue it if it is real.

kekpsp said...

THE ULTRAHLE N64 PSP EMULATOR IS REAL, NOT A FAKE
AMAZING!!!!!!

Morgan said...

StrmnNrmn you said by early July you could have something for us, such as R6? Well it's now July 5th so maybe could you post here about progress or whatever you've been working on since you returned from vacation. Also I mentioned using the Media Engine now that most PSP's are 1.5 is this a possibility? Thanks for your hard work thus far and please never give up!

wally*won_kenobie said...

People shouldnt be whinging about a release yet. Surely Strmnnrmn is working hard on it now.

No need for ME support yet, its not even optimised properly, graphics arent correct, no sound. ME probably wont do much unless sound is put in it (Thats about all that it can take)

So before you go biting his neck and sucking blood I suggest you wait

ukcuf16 said...

^well put wally wally.

kekpsp said...

Strmnnrmn dont lose faith in what you are doing for the PSP homebrew community, I know that the competition is getting tough, and I can now say that Mario at least can be made to run at about 30fps with sound on a PSP 1.5, but the prospect of having a fully functional multi rom N64 emulator for PSP is the holy grail at the moment, keep up your sterling work, good luck with R6... come on everyone, a bit of support for Strmnnrmn :)

tsurumaru said...

kekpsp

I'm interested in the comments you have made about the UltraHLE N64 emulator, I've done a pretty thorough search on it and the only follow up to the original news posts that I have found is the vague promise of a closed "release" on the 14th July in the PSP updates comments section. From previous experience it sounds like another "fake" in my humble opinion.

Since you have posted about it working so well I wondered if you could share what information you have to base your claims on? ie have you had a beta copy that you've been testing? It would of course be great news for the scene if it were to turn out to be genuine.

Thanks for your time. :)

Strmnnrm - Hope everything is going well, take as long as you need for the next release ;).

kekpsp said...

Tsurumaru, all I can disclose at the moment is that there seems to be a race on to develop a full speed N64 emulator for the PSP single rom and multi rom veriations, there are quite a few devs working on this, and a few of the older PC emulators are being converted with varying degrees of success, there are going to be some tasty surprises, and yes it will benefit us all, please be patient, its going to be a fantastc month for the community

flyinghippo said...

After finally downloading R5 and reading readme.txt, it is stated that the C buttons are not yet mapped out. Since the O (circle) button has not been put to use, perhaps you could implement a combination of O and the Direction-Pad.

I too am anticipating R6. Good luck with all future builds.

ukcuf16 said...

I think the cbuttons should be mapped out on the dpad without pressing o since no 1 actually uses dpad for n64.

Morgan said...

That is very true I don't ever really remember using the dpad really EVER! But yeah StrmnNrmn are we close to a release because you did say at around this time you "would have something for us". I'm not trying to hurry you along I'm patient and I want the best emulator you can build I just want to know if we are close and if you maybe had a date?

flyinghippo said...

There are still plenty of games that use the D-Pad, such as Pokémon Stadium, which heavily relies on it. It shouldn't be something left out.

Morgan said...

If you are cheering on StrmnNrmn to build this emulator so you can play pokemon stadium. Are you a complete clown or what, take that stupid game and throw it away. Give me some goldeneye, starfox, diddy kong racing, mario 64! Pokemon you should be ashamed of yourself. Kepp up the great work StrmnNrmn!

Morgan said...

Plus how are you going to play pokemon stadium if you had to have your gameboy cartridge hooked up, come on man think!

Exoskeletor said...

hello friend, what about sound? :)
When we will have sound even not perfect?

Morgan said...

Sound won't probably be for a while because sound would GREATLY slow down the emulator. Sound will probably be implimented in a much later release. Keep up the great work StrmnNrmn!

Morgan said...

Sound won't probably be for a while because sound would GREATLY slow down the emulator. Sound will probably be implimented in a much later release. Keep up the great workk StrmnNrmn!

Morgan said...

Sound won't probably be for a while because sound would GREATLY slow down the emulator. Sound will probably be implimented in a much later release. Keep up the great work StrmnNrmn!

Morgan said...

Sound would greatly slow down the emulator so I don't expect sound for a while.

wally*won_kenobie said...

Heh PSdonkey is being tricky.

Hes using Strmnrmns emulator and taken screenshots of those games. OR

used photoshop and added noise to the pictures.

Donkey get Goldeneye into one of those pictures then i will believe you.

Morgan said...

Are you talking about the build with the music in the backround (r5 remix) that was just a pic from the emu and the sound from mario in atrac3. Just a eboot file customized, I do that with all my eboots.

Disturbd1 said...

Wow, no updates in like what, 2 weeks already... Where is this guy, lol... Any1 heard from him? Thought there was going to be a release of R6 rly soon.

Morgan said...

StrmnNrmn probably is hard at work, I hope he's working and that's why we haven't heard from him. But yeah StrmnNrmn you could at least give us an update or at least a comment saying something new.

StrmnNrmn said...

Argh - tons and tons of comments here! Apologies for the late replies :( I'm going to tackle a few of these before I head off to bed :)

frmariam: I suspect the memory leak I just fixed may have been responsible for the freezing you talk about. The main difference between R4 and R5 is the dynarec (which uses a lot more memory). I think the reason you're seeing the freezing happening earlier is because R5 is running out of memory more quickly. Hopefully the memory leak fix will sort this out for you.

flyingbuzz: There are actually three areas I'm looking at doing this for: matrix/vector manipulation, texture format conversion, and triangle setup. I think these three things account for most of the time spent processing display lists, so I'll be looking at doing this as I improve the dynarec performance.

sroon: I think a frameskip option is always going to involve a tradeoff between lagginess and overall speed. At least if it's an option people can choose whichever they prefer.

cms108: long time no see indeed mate :)) Seems like eons ago that we were disassembling roms for the first time in Wellington street!
You could probably preprocess some stuff in advance. I think with the dynarec the idea is just to get the cost of recompiling so low that it's insignificant compared the the time spent executing it. It might make more sense to pre-convert textures, but it would take a lot longer to read them from the memory stick, and I'm not sure there's enough free memory to hang on to them there :(
It's definitely worth trying to get both PSP cores fully utilised. One idea I was playing with was to emulate the CPU on the first core, and RSP (including display/audiolist HLE) on the second core. The n64 code should handle all the synchronisation issues itself, which is nice.
Anyway, I'll have to drop you a line soon. Did you know Steve had a sprog?!

morgan: Any links about a fullspeed emu for those roms seems to have gone now :( In any case, competition is always good :)
Yup, I agree taking advantage of the ME needs to be investigated.

flyinghippo/ukcuf16/morgan: A few people have suggested this usage of the O button. I've got this working in my R6 build, but I'd like to make it configurable (i.e. at least whether the default state is for Dpad or Cbuttons)

exoskeletor: Unfortunately I think sound is going to be some time away :( Like morgan mentions (several times :) it will slow things down somewhat, and while the framerate is like it is now, it'll sound all choppy and horrible.

disturbd1: Me too :)