Ridge Racer 4 Pandora?


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! :ph34r:
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.
 
Last edited by a moderator:
Very cool. Thanks Tinnus.

EDIT: OK, I see now that by "Ridge Racer 4 Pandora" it meant "for" not RR4. :p Now the pics make total sense.
 
I think Tinnus is saying Ridge Racer 4/for Pandora (like snes4iphone). Not saying that is a shot of Ridge Racer 4 running on pandora.
 
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.
 
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 :p
 
Last edited by a moderator:
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. :)

Exophase said:
There will be OpenGL ES 2.0 libraries for it eventually.
Ah, ok...
Squidge said:
Correct. However, most of the features will be exposed via OpenGL.
...so the Situation is more like on PC's....
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.
...Hardware Access via Drivers. Hm, OpenGL is very Powerful so it could work...
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.
...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"...? ^^"""
 
Last edited by a moderator:
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): :p
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?

I don't like the stretched edges much.

I like your idea, maybe instead render to a 720x540, that way you only lose 30 pixels on the top and bottom, and have 40 pixels on each side Pillarboxed. Or something similar, like 700x524 with 22 pixels cut off top and bottom, and 50 pixels per side pillarboxed (I don't have any idea how this would work in execution)


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.
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.

I think that Namco tried to make it a 60fps launch title, and failed, but the code is still all screwy from that.
 
Last edited by a moderator:
fusion_power said:
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.
...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"...? ^^"""

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?
 
Last edited by a moderator:
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"...? ^^"""
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 TTM :)
 
Last edited by a moderator:
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.
 
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.
perfect graphics? Or PS1 correct graphics.


Good question though, is the ram part of the system ram? Or is it impossible to modify the addresses?

Or is it that the PowerVR core has some ram of its own inside?
 
Last edited by a moderator:
Firefox said:
We'll still have direct access to the framebuffers though, won't we...?
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.
 
Last edited by a moderator:
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?
 
Last edited by a moderator:
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.
 
Last edited by a moderator:
Back
Top