Hyperpc
Member
nice but it aint ridge racer type 4
There will be a possibility of reverse engineering the damn thing too. But I hope the libraries will do their thing properly and that won't be needed.fusion_power said:Sounds like nobody will have access to the important Hardware Accelerators of the Pandora? All have to be done in Software? No use of the powerful Chipset Features for Homebrew-Devs? Please say, I'm wrong! h34r:
Lobo said:Ridge Racer 4 would probably run BETTER than RR 1.
I recall that RR ran atrociously bad on the GP2X whereas other car games weren't as bad, which was surprising since it was one of the very first games for the Playstation and was therefore not "squeezing" the consoles capabilities as much as a later game would have.
And RR1 was badly programmed exactly due to that.
Anyway, the "4" means "for", and it's RR Revolution
Tinnus said:fusion_power said:Impressive Pix. I'm sure, the Pandora can handle this game but the big Question is: Full Speed?
Based on the performance of the GP2X version, the numbers TI gives about the peformance of the CPU, and the speed of the GL ES 2.0 GPU, we judge it will easily be fullspeed right away
Cool.
Ah, ok...Exophase said:There will be OpenGL ES 2.0 libraries for it eventually.
...so the Situation is more like on PC's....Squidge said:Correct. However, most of the features will be exposed via OpenGL.
...Hardware Access via Drivers. Hm, OpenGL is very Powerful so it could work...DJWillis said:Your not quite right .
The PowerVR hardware is VERY closed however drivers allowing the hardware to process OpenGL ES and OpenVG (I hope) commands will be available for the Pandora in time. These features will be accessible by developers as an abstract wrapper to the hardware.
...I hope this to. But can such a "Driver-library-thing" as effective as straight Access to the Hardware? I mean like Commercial Coders have Access to the PSP or NDS or Console Hardware...IF they have this, I don't know much about commercial Development for the Consoles and how the Devs do it. Do they use Drivers to or is everything done with some kind of "direct access"...? ^^"""notaz said:There will be a possibility of reverse engineering the damn thing too. But I hope the libraries will do their thing properly and that won't be needed.
EDIT: But, what about an optimized mode (like the one existing in most LCD TVs), that reduces the distortion on the center of the screen?CoMiKe said:I would prefer the future Pandora PSX emulator to render at 800x600, but showing only 800x480.
I think removing 60 pixels from both top and bottom won't make as lose too much relevant screen info.
Well, this game isn't a good example (it loses the digital speedometer and the sixth gear indicator):
Agreed, I hear it was because the physics was trying to run at 60fps, and half of the stuff got rendered at 30fps. Just a terribly coded game.Lobo said:Ridge Racer 4 would probably run BETTER than RR 1.
I recall that RR ran atrociously bad on the GP2X whereas other car games weren't as bad, which was surprising since it was one of the very first games for the Playstation and was therefore not "squeezing" the consoles capabilities as much as a later game would have.
fusion_power said:...I hope this to. But can such a "Driver-library-thing" as effective as straight Access to the Hardware? I mean like Commercial Coders have Access to the PSP or NDS or Console Hardware...IF they have this, I don't know much about commercial Development for the Consoles and how the Devs do it. Do they use Drivers to or is everything done with some kind of "direct access"...? ^^"""notaz said:There will be a possibility of reverse engineering the damn thing too. But I hope the libraries will do their thing properly and that won't be needed.
Well, if I am correct the Nintendo folks use a SDK with libraries just like everyone else (for the wii they just updated the libraries and the SDK due to the similar hardware). I don't see a problem with OpenGL for rendering, who cares how it goes about it if the power is so enormous?
The PSP uses a bunch of libraries and so does the DS. I don't know if this is the only way however, but it most probably makes it all easier (else whats the point?) and companies like easier as it means faster TTMfusion_power said:...I hope this to. But can such a "Driver-library-thing" as effective as straight Access to the Hardware? I mean like Commercial Coders have Access to the PSP or NDS or Console Hardware...IF they have this, I don't know much about commercial Development for the Consoles and how the Devs do it. Do they use Drivers to or is everything done with some kind of "direct access"...? ^^"""
perfect graphics? Or PS1 correct graphics.Tinnus said:I just wanted direct VRAM access like in the PSP for setting the draw buffer, texture and LUT addresses, etc manually. Would make emulating things like the PS1 (with perfect graphics) much easier.
Yes, all you need do is open /dev/fb0 and mmap the returned pointer. Please don't try to access the memory directly (like on the gp2x) as it may change.Firefox said:We'll still have direct access to the framebuffers though, won't we...?
Squidge said:Yes, all you need do is open /dev/fb0 and mmap the returned pointer. Please don't try to access the memory directly (like on the gp2x) as it may change.
OK, but then any way to give pointers to OpenGL? For example, will glTexImage2D always copy the image data somewhere or will it only use the pointer (ie: I can call glTexImage2D every frame to change texture pointers/data around in realtime)?
Will the mmap'ed pointer to /dev/fb0 be the same framebuffer with the data the GPU writes?
Would I be able to set the framebuffer pointer manually?
Tinnus said:OK, but then any way to give pointers to OpenGL? For example, will glTexImage2D always copy the image data somewhere or will it only use the pointer (ie: I can call glTexImage2D every frame to change texture pointers/data around in realtime)?
OpenGL always copies the data unless there is a specific extension like GL_APPLE_client_storage.