|
|
|
|
[Via StrmnNrmn]
Permalink |
Email this |
Linking Blogs
| Digg It!
Bookmark / Find this article on: |
|
32 Comments
|
well then what the hell can he do!?
lol monaco actually gets credit for once :P
hahah monaco.. lol
Good information I suppose... not what I'd like to hear... but I fully support your progress strmnrmn, and find your updates useful. I hope you can find other ways to make your N64 emulator for the PSP even better. And is it just me or are the comments 1-2 and 4-5 just plain idiodic and off the subject... Well guess thats what the unregistered comment filter is for...
glad you guys noticed the credit given ;)
Yay, Good Job StrmnNrmn. I can't wait for your next release
and keep up the good work :D.
Any estamate on when this might be finished?
I'm first to comment!!!!, way to go me , just kidding , anyways I fell a bit impatient for this N64 emulator to be updated but I know it's hard making this so lets give them time , anyways this will be awesome , I always thought it would be cool playing legend of zelda ocarina of time in your psp :)
Wow, a non-news story. Just a way to fill up space, eh, QJ.net?
@OP - You say it is "non-news", but in basic journalism, it is news. StrmnNrmn talks about speed improving, and explains that all of these ideas are great, but it just isn't as logical as many may think. This should be the overall message that we learned from this article. Or, you can take it my way - StrmnNrmn has posted some news for us stating that he is focusing on CPU Emulation and speeding that up, these smaller tricks will not suffice
damn u was late as hell numver 14
Looking at number 18.... another great reason for using the unregistered comments filter. While you, Mister Op may only appreciate homebrew releases, some of us here actually like to read about things. Keep up the good work QJ.
Come on even the PC version required min of 500MHZ PIII to run. That a min requirement is not a recommended requirement. Now some how the port is going to run on a 333MHZ CELL processor. Sorry I just don't see it happening!
Yes I know that HZ don't matter they are different cpu structure, but I still can't see it happening.
Just look at DGEN or SNES emulator both of them can't run full speed on the PSP without some frameskip.
I'll tell you what I would like to see though is a emulator for the PSone, but first someone have to find the source code for Virtual Game Station which has to be the best PSone Emulator ever. To bad sony bought it and now we will have to wait for it to be ported by sony in the 3.0 firmware.
this emu will be working great if not 100% it will be 90% and that my friend is good enough
might take long like 1-2 yrs but I believe that this emulator will get to 100% speed or at least pretty close. keep working on the emulator StrmnNrmn =)
if u do both thats a 0.67fps imrovement :D
I never owned a N64, never played one longer than a few moments nor knew anyone who gave a hoot about it. The standout memory of it is being bargain binned for under a c-note with two controllers and a few titles. That said, I was excited to see what this platform had to offer on the PSP but there is know way that I feel confident that I would get any satisfaction nor feeling of respect for the N64 with this emulator port. Monkey is the same.
Surprise me. Please. Otherwise these fractional frame rate adjustments and pure speculation needn't waste bandwidth.
what is wrong with frameskip... i know for a fact that with the snes emu i use(it is a really old emu i think its SNES9x but i dont know the exact version but its perfect just no wifi for it) i get 40-60 fps on 2.6 if i run it at 333mhz. i use only 1 frameskip on it and the quality doesnt go down. unless the emu is using too much of a skip.like if i put it up to 9 it will definitely look chopped up and just horrible and will give it like 10 fps but a frameskip would be good. not that it makes a big difference. if it was something easy to put in i would try it myself so i could at least force the emu to be playable.(its playable now but its still slow)
eggwonder,
With most emulators of 2d systems, the bottle neck tends to be in the drawing routines (rasterising the display) since it's usualy all software drawn. Hense frameskip can make a huge impact on the performance.
Now for n64 emulation. Both Daedalus & M64 have the hardware rasterise the display. Not to mention this is all off loaded to the Graphics processor and does not tie up the CPU.
So really all a frameskip would pass over on the cpu is parsing a new N64 Display list via HLE.
In N64 emulation, the serious bottleneck is and always will be the CPU emulation, Not the GPU (in n64 case, the RSP & RDP).
Instead of a stunted N64 emulation, I think GBA is more of an approriate target. Good to see some new attention directed there today.
Still, the advancements made with N64 are impressive, and I don't mean to detract from them.
Is it really feasible that we will see an emulator for the N64 on PSP to run at full speed? The only way I could see this happening is if somehow Strmnnrmn was able to reduce the resolution to a smaller size so that the CPU will have an easier time processing the graphics, but I believe he said sdoing something similar like that would not yield results unfortunately.
The other thing is that the current SNES and Genesis Emulators don't quite run at 100% smooth speed without reducing the frame rate, and these are rather primitive compared to N64. Even though I applaud STMNNRMN's effort and I really hope he proves me wrong on this, I think it might just be a pipe dream to see a decent N64 emulator with playable speeds that will ever happen on the PSP.
not ush, but any speed improvemnt is good news
Please read my comments above. Drawing the graphics are not the bottleneck in n64 emulation. Regardless of the render resolution, The n64 still must perform the exact same amount of CPU instructions before It renders anything.
Again, on top of this all drawing calls are patched to PSP GU (graphics unit) calls. So the PSP GPU (NOT CPU) is rendering/rasterising all the 2d & 3d. So actual drawing has no bottleneck on the cpu.
The only place in actual drawing that could bottleneck the fps a few frames is texture conversions from n64 to a native psp format. Yet with some texture cashing this is less of an issue.
frameskipping definately speeds up other emulators by a substantial amount (a lot more than just 0.5 fps)... maybe u should recheck that...
I guess I'm optomistic about the whole N64 emulation. Only thing I care about is whether or not I can run it on my 2.6 :P...LOL . So keep up the good work StrmnNrmn :D ( just don't forget us 2.6 ers...mmkay ;-)???...lol)
The Corn emulator was never fully finish, but it was able to run full speed on a 233mhz cpu. What do you think PSmonkey maybe there is an answer to your cpu speed problem in that emulator?
Well any improvements are good news. keep it up.
@35 - maybe you should recheck the thread. Its actually been answered by post 34, and others.
@37 - Your comparing apples and oranges. I would think a ported pc emulator would run much slower on the psp. These emulators are being designed from the ground up on the psp.
Most of emulators for psp have been ported to the psp from the PC. DGEN SNES9X even Daedalus
You should really rethink what you want to say before posting. Like I said in one of my earlier post I know there is a difference between cpu structure, so they can't be full compared. What I can tell you is that a 333mhz psp cpu is faster that 400mhz pc cpu by how much I don't know. Now from what PSmonkey was saying is that the cpu emulating seems to be the point of the slowness in both N64 emulators. I was only pointing out that out of all the PC Emulators for N64 that Corn was fastest. It has been able to run on a 233mhz which 2 - 3 times less cpu power as most N64 emulators have required . So it's only safe to say that the developer of the corn emulator may have a more optimal way or emulating the cpu.
You're correct. There is something in corn that is a good solution to the problem.
I've been talking with zilmar about this for quite some time. One of the reasons corn is so fast is treating the primary instruction set as 32bit (which it is) but most emulators tend to do stuff in 64bit when executing 32bit instructions. On the psp this is a huge problem since the psp registers, pipeline and etc are all 32bit. So even simply storing a simple value (which is in a 64bit register) ends up costing alot more instructions then it needs to.
I hope my next build of m64 will be able to run with quite a few instructions in 32bit which should boost the fps a few frames. It wont be the end all solution to improved speed but it's something that should be tackeled before I eventualy move onto a recompiler.
If a PSone emulator is possible then I can't see why a N64 emulator can't be possible, both systems games have basically the same poly counts, etc...
It would just depend on how much cpu is needed to perform the emulation and I guess how different the PSOne and the N64 cpu's are compared to the PSP's.
|
The QJ.net Network |
|
| Site | Feed |
| QJ.NET | RSS |
| Nintendo DS | RSS |
| PlayStation 3 | RSS |
| PSP Updates | RSS |
| Wii | RSS |
| Xbox 360 | RSS |
| MMORPG | RSS |
| Personal Computer Games | RSS |
| iPhone - iPod Touch | RSS |
| QJ.NET Forums | RSS |
| Most Commented | |
| (83) | |
| (55) | |
| (43) | |
| (35) | |
| (34) | |
| (30) | |
| (27) | |
| (25) | |
| (22) | |
| (21) | |
| (19) | |
| (18) | |
| (17) | |
| (15) | |
| (13) | |
| (13) | |
| (12) | |
| (11) | |
| (11) | |
| (10) | |
Accessories
(615)Add-ons
(87)Applications
(176)Artwork
(81)Batteries
(18)Cheats
(63)Deals
(264)Events
(160)Firmware
(338)Flash Applications
(20)Flash games
(33)Game Demos
(34)Games
(5881)Hacks & Exploits
(441)Homebrew Applications
(4694)Homebrew Demos
(73)Homebrew Development
(891)Homebrew Emulators
(1173)Homebrew Games
(2405)Homebrew Themes
(18)How-To
(222)Humor
(51)Imports
(231)Interviews
(628)Magazines
(310)Mods
(211)MY QJ
(14)News
(7616)Off Topic
(603)On Shelves This Week
(30)Opinions & Analysis
(478)Podcasts
(25)Previews
(1669)PSP Go
(87)PSP Minis
(7)PSP Slim & Lite
(124)QJ How-To Series
(11)QuickJump QuickGuide
(18)QuickJump QuickPeek
(36)Reviews
(114)Rumors
(491)Scans
(170)Screenshots
(702)Site News
(174)UMD Movies
(180)Videos
(1727)Weekend Warrior
(71)Wi-Fi
(203)
Emulators
Amiga 500
(29)Amstrad CPC
(28)Apple II
(1)Atari
(64)BBC Micro computer
(8)Capcom Play System 1
(36)Capcom Play System 2
(42)Chip 8
(9)ColecoVision
(21)Commodore 64
(20)DosBox
(11)Gameboy & Gameboy Color
(91)Gameboy Advance
(64)HitBit
(8)HP48
(9)Intellivision
(9)J2ME
(3)Macintosh
(9)MAME
(23)MGT Sam Coupé
(7)MSX
(52)Neo Geo
(116)Nintendo 64
(128)Nintendo NES
(60)Odyssey
(1)PC-8801
(6)PC-9801
(7)PlayStation
(26)PSP
(45)ScummVM
(21)Sega Gamegear & Master System
(37)Sega Genesis Megadrive
(52)Super Nintendo SNES
(87)Tandy Color Computer/ Dragon
(1)Thomson MO5
(4)Thomson T07-70
(8)TI-92
(7)TI-99
(3)Turbo Grafx 16 & PC Engine
(54)Vectrex
(4)Virtual Boy
(0)Wonderswan
(30)X86
(1)ZX Spectrum
(10)ZX81 Sinclair
(7)
Titles
Archives
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
StrmnNrmn recently updated his development blog with some answers to a few crucial comments by users. The first question asks about resizing the screen to half of the original height, and adding empty lines in between to optimize speed. StrmnNrmn has concluded that while this is a good idea, and has been used in many tech demos from developers, it will not show a considerable difference. He uses Zelda as a model for estimating the speed improvements, and concludes that, at most, the frame rate will be improved by 0.17. This is a very small amount, something which is not noticeable. 
