gp2x, take two: Pandora (formerly craginator) port of Cube?

by CC_machine#928346198 on 08/08/2008 22:05, 16 messages, last message: 08/13/2008 20:50, 3265 views, last view: 04/24/2024 02:22

The Pandora handheld console will make it's debut around september. It has full SDL and OpenGL acceleration: it will support OpenGL ES 2.0. The unit has 128MB of ram, the "PowerVR SGX 530" GPU ("several million polygons per second", see the wiki) and a 800x480, 4.2 inch screen. It has a touchscreen, dual analog nubs and traditional digital buttons for control. The device is fully open and ready for homebrew development.

Since the device is ARM-based, it would require porting to run cube on the unit. Who would be interested in porting Cube 1 or possibly even Sauer onto the upcoming device? with all the content available for Cube 1 and/or sauer, it'd likely need little work to ensure hours upon hours of play once done. As the device will be the most powerful handheld in the world both in terms of CPU and GPU horsepower, i doubt there would be many performance issues.

There is a thread on the Pandora forums, here: http://www.gp32x.com/board/index.php?act=ST&f=62&t=43486&st=0#entry634542

Main Pandora site: http://openpandora.org/

So, who'd like to Cube on the Move? :-D

   Board Index   

#1: ..

by Julius on 08/08/2008 23:24

+1

There is also a program to provide developers with free units :)

reply to this message

#2: ..

by SheeEttin on 08/09/2008 00:16

Considering that there was once a Cube port to... uh... what was it? Something handheld... yeah, I'd expect that if a coder here gets their hands on one, we'd probably see Cube or Sauer running on it eventually. :)

Hmm, I'd like to get my hands on a finished Pandora...
Just think, no more waiting to get home when you're out and you're struck by inspiration (and don't have a laptop, or one that can run Sauer). You can just pull out your Pandora and map away. :)

reply to this message

#3: Re: ..

by CC_machine#928346198 on 08/09/2008 13:25, refers to #2

i've been tinkering with sauer code and have been developing some simple projects for the gp2x and got them to run, so I might try it.

any other devs interested? i guess we should wait for the device to be released first.

reply to this message

#4: Re: ..

by SheeEttin on 08/09/2008 17:43, refers to #3

Nonsense.
Nothing like a good game available upon release. :)

reply to this message

#5: Message censored by administrator

by nooomas on 08/09/2008 21:42

#6: bigger file, so?

by CC_machine#928346198 on 08/09/2008 23:48

@noomas: quality games have more content, better graphics ect... so yeah it takes longer to download, more files. that's how the net works.

why post that here and not in the general thread anyway? 0.o

reply to this message

#7: Re: ..

by Quin on 08/10/2008 02:26, refers to #3

Yes, I wouldn't mind maintaining a Blood Frontier port. Anyone wanna buy me one? :P

reply to this message

#8: Re: ..

by CC_machine#928346198 on 08/11/2008 15:00, refers to #7

this thing has wifi, analog nubs, a 800x480 touchscreen, dual SDHC slots and is the most powerful handheld to date - costs way too much to be donated ;P

btw i looked at the memory usage and it never goes above 90mb running with maxtexsize 256 and mintexcompressize 128 for a map that's loaded when sauer starts - good seeing as the pandora has 128mb =]

the memory usage goes up as more maps are loaded though, i'm guessing it keeps used textures loaded from previous maps. makes sense for high end PCs, but we'd have to optimise that for the Pandora somehow.

reply to this message

#9: Re: ..

by tentus_ on 08/11/2008 17:27, refers to #8

Yeah, I get just under 90mb when i start... load up another map and start working my way through the F2 pages, and see a ~.5 meg increase per page.

A possible solution would be to simply flush out the textures every time a map with a different texture set is loaded. It'd slow your load time down, probably significantly, but it's the most elegant solution I can think of.

reply to this message

#10: FP

by Aardappel_ on 08/11/2008 18:47

http://www.arm.com/products/CPUs/ARM_Cortex-A8.html

sounds to me like it has no hardware floating point. Porting Cube to fixpoint is a LOT of work.

The OpenGL ES part should be doable since Cube uses absolutely simplistic OpenGL. I wouldn't think of sauer as that would require major reworking.

The intel PDA that Jeff Rous ported it to seemed to have similar power to this thing, and it didn't run all that fast. It would probably be easiest to use exactly his version of Cube. Maybe he'd like to help?

reply to this message

#11: ..

by Julius on 08/11/2008 19:20

It can do single precision floating point operations on a co-processor quite fast (I gathered, but I am no expert):

[quote]
What I mean is that it's possible for Cortex-A8 to use run many single precision VFP opcodes on the NEON unit (so they're pipelined and not so slow). But this only happens when specific conditions are met. It might not yet be possible to do so in GCC. I'd be very curious if you could hack the conditions and see if the FPS change, and how much (if it still works).Just bear in mind, that without this, and for the instructions that are not supported, VFP is pretty slow. It's more there for compatibility sake than to be highly useful.From Cortex-A8 TRM:
CODE
13.5.4 RunFast modeRunFast mode is the combination of the following conditions:• the VFP coprocessor is in flush-to-zero mode• the VFP coprocessor is in default NaN mode• all exception enable bits are cleared to 0.In RunFast mode the VFP coprocessor:• processes subnormal input operands as zeros• processes results that are tiny before rounding, that is, between the positive and negative minimum normal values for the destination precision, as zeros• processes input NaNs as default NaNs • returns the default result specified by the IEEE 754 standard for overflow, division by zero, invalid operation, or inexact operation conditions fully in hardware and without additional latency.
And...
CODE
16.7.2 VFP instruction execution in the NFP pipelineThe NFP pipeline can execute a subset of the VFPv3 data-processing instructions more quickly than the VFP coprocessor. The following constraints define which VFP instructions are executable by the NFP pipeline:• single-precision data-processing operations only• RunFast mode must be enabled• scalar only or non-short vector instructionsIf these constraints are met, the following instructions can execute in the NFP pipeline:• FADDS, FSUBS• FABSS, FNEGS• FMULS, FNMULS• FMACS, FNMACS• FMSCS, FNMSCS• FCMPS, FCMPES• FCMPZS, FCMPEZS• FUITOS, FSITOS• FTOUIS, FTOSIS• FTOUIZS, FTOSIZS• FSHTOS, FSLTOS• FUHTOS,FULTOS• FTOSHS, FTOSLS• FTOUHS, FTOULS.VFP instructions that execute in the NFP pipeline have results that are 32-bit single-precision writes to the upper or lower half of the 64-bit register value. A restriction that applies to VFP instructions executing in the NFP pipeline is that instruction results cannot be forwarded early to subsequent instructions. [quote]

And the Cortex A8 is much faster per mhz than the ARM xscale CPUs, and can be made to run at up to 900mhz-1ghz.

reply to this message

#12: ..

by Julius on 08/11/2008 19:24

What I ment was the PDA was most likely a xcale CPU and the Cortex A8 is more than twice as fast per Mhz.

reply to this message

#13: Re: ..

by Quin on 08/12/2008 04:04, refers to #8

Big joke anyway. For anyone who knows me, I need a decent computer before I go piddling with other stuff :P

reply to this message

#14: ..

by CC_machine#928346198 on 08/12/2008 19:14

thanks aard, I'll query that on the pandora (gp32x) forums. i remember that the GP2X compiler toolchain i used also had issues with floating point numbers in my C++ code - i never bothered to look up for a solution though.

the Pandora is very powerful though. look up the specs on the GPU, it can easily outperform the PSP in terms of fancy shader, bumpmapped etc effects.

reply to this message

#15: Re: ..

by sdhjkfconorfdhskj on 08/13/2008 01:02, refers to #3

GP2X? Could you release the code for that, as the iPod is *very* similar to the GP2X and I know a project who would love this kind of thing. (I am talking about older iPods, not the new nano's touch or classics)

reply to this message

#16: sauer uses single or double precision floats?

by CC_machine#928346198 on 08/13/2008 20:50, refers to #15

I posted a thread on the pandora board and apparently the ARM Cortex A8 has two FPUs (though they cannnot work in parrallel:

- VFPlite : it has support for single and double precision floats; it\'s not pipelined and hence slow
- NEON : it only supports single precision floats and is pipelined.

would sauerbraten require single or double precision float support? that\'s the question. when i have some good spare time i\'ll have a thorough look through the source.



P.S. @sdhjkfconoifddhskj: hm? i\'ve not got cube or sauer to run on the gp2x, they\'re my own little projects starting out with C++ and SDL, nothing really worth porting to an iPod.

besides, the iPod has nowhere near enough buttons to play them x]

reply to this message

   Board Index