What About Some Decent Ports?

[Megatog615]

In my humble opinion, Quake 3 should be ported and used as the killer app for the Pandora. http://ioquake3.org is a good starting point.

 

[PokeParadox]

Yes, and with the touch-screen, FPS games should control much better than on the 2X!

err, pandora has two analog sticks, why on earth would you use the touchscreen?


Analogue sticks are fine if that's the only option you have... but if you have something designed for pointing, then it makes sense to use that to aim... or am I the only one that sees that intuition? :huh:
Regardless, controls should be as configurable as possible. I'm not trying to shoehorn you all into my way of thinking, although seemingly you are... :unsure: But Playing Metroid Prime Hunters on the NDS would show you that touchscreen for aiming does work for portable FPS games.

I love Metroid Prime Hunters as much as the next guy. It's a brilliant game, but exactly how would you use the touch screen on the Pandora?

I can see the following problems:
* The Pandora only has a single screen, and it may look cluttered with both the HUD and the stylus in the way.
* An FPS would be difficult to play on the Pandora without sitting it on a surface, as you may only have one hand to hold the base with.
* At least one hand will be on the touch screen (to move the reticle), so the other hand will either be moving your character around or shooting. How will you be able to do both if the touch screen is on the top half and the buttons are on the bottom?

Metroid worked great on the DS because the touch screen was on the bottom half, which was also where all the buttons were. That left the top half with the gameplay screen clean. With all the weight and buttons on the bottom half of the Pandora, I can't imagine trying to hold it by the top screen and aim at the same time, let alone somehow reach the buttons.

I love FPS' too, but I can't see them taking advantage of the Pandora's touch screen for aiming. Maybe on an on-rails shooter, but not an FPS. I'm probably talking out of my ass and I don't know a great deal about the Pandora, but I'm really having trouble picturing playing a touch screen FPS.


Thing is, we won't know until we try and use the screen. Since posting those earlier comments similar concerns about how usable the screen would be occurred to me. I'm guessing the best option is allow several control schemes. I'm sure for simpler fps games the screen could be used.
Tap screen to jump
Hold screen with one hand
press the L or R button with pinky to shoot

OK so that's less than ideal since most peoples' pinkys aren't used to rapid hammering of a button, but something will be possible and it might be usable for some people, we won't know until we have the Pandora in our hands.

 

[sephiroth111]

Using Libpurple, a Gaim/Pidgin clone (http://pidgin.im) using SDL.
SDL calander/ productivity apps.

i'll probably end up making something that mimics the stuff i use my phone for.

 

[Pickle]

Using Libpurple, a Gaim/Pidgin clone (http://pidgin.im) using SDL.
SDL calander/ productivity apps.

i'll probably end up making something that mimics the stuff i use my phone for.

i like it! Although if you dont have a window manager thats the only thing you could run.

 

[Megatog615]

Why not just port Pidgin?

 

[javaJake]

GTK is heavy. Any Gentoo user can tell you that from experience.

 

[Yrx]

Okay, so I have a question.

Cave Story has already been ported to GP2X, so I assume it will be easy to port to Pandora. Is there any way that the resolution could be changed to fit the widescreen display? Even if it were just doubled pixels and the view extended. I'm not a developer, so I really have no idea how feaible this is.

 

[Chip]

Okay, so I have a question.

Cave Story has already been ported to GP2X, so I assume it will be easy to port to Pandora. Is there any way that the resolution could be changed to fit the widescreen display? Even if it were just doubled pixels and the view extended. I'm not a developer, so I really have no idea how feaible this is.

It is doable, it just requires doing. Expanding the graphics to fill the display is well within the realm of possibility.

Since the ARM Cortex A8 used by Pandora is pretty much backwards compatible with the ARM7, I'm curious about the possibility of a WINE-like compatibility layer for all old GP2X (and maybe even GP32) programs. This would eliminate the need for all the old programs to be individually ported.

In fact, I think this should be a priority for early Pandora development. Out-of-the-box backwards compatibility would be a huge selling point, as it was with the GBA, DS, and PS2. Not for nothing, but an app that enabled hundreds of pre-existing GP2X games to run on the Pandora would probably win any coding competition

 

[Nr.56]

ports of the some typical Linux GL games would be nice:

Sauerbraten, TORCS, Balazar or Vegastrike ... maybe enabled by slimmed (but compatible) engines

 

[Ravnos]

GTK is heavy. Any Gentoo user can tell you that from experience.

The UI for Nokia's Internet Tablet OS is GTK-based and it runs fine on a 400MHz ARM with 128MB of RAM. Pidgin runs great on it, too. I'm sure it will be just as good (or better) on the Pandora.

 

[javaJake]

Sauerbraten, TORCS, Balazar or Vegastrike ... maybe enabled by slimmed (but compatible) engines

Vegastrike? TORCS? Are you kidding? I will be absolutely shocked if the Pandora can run that. That game is graphically intense for my computer, let alone a handheld. However, Vegastrike is an awesome game - they give you that spacious feeling of flying around in space.

 

[Tobriand]

Well, Vegastrike says it should run on a Pentium 200MHz, so CPU-wise, Pandora should be able to handle it (considering that this time round we'll be using a chip with an FPU afaik - yay).

However, it does also point out that it wants 512mb ram (with a side-note that it does - just - run with 256). That said, I don't remember any P1 200MHz machines having that much, so, presumably, it may be possible to hack it to run on lower by sucking all the high-res goodness from the textures. Maybe.

 

[ldesnogu]

(considering that this time round we'll be using a chip with an FPU afaik - yay).

Don't get overexcited about Cortex A8 FPU, it's not pipelined

 

[PokeParadox]

Well, Vegastrike says it should run on a Pentium 200MHz, so CPU-wise, Pandora should be able to handle it (considering that this time round we'll be using a chip with an FPU afaik - yay).

However, it does also point out that it wants 512mb ram (with a side-note that it does - just - run with 256). That said, I don't remember any P1 200MHz machines having that much, so, presumably, it may be possible to hack it to run on lower by sucking all the high-res goodness from the textures. Maybe.

Exactly, a lot of ram can be freed by reducing texture resolution, sine their standard res will be overkill for the size of display we have on Pandora.

 

[Pickle]

Well, Vegastrike says it should run on a Pentium 200MHz, so CPU-wise, Pandora should be able to handle it (considering that this time round we'll be using a chip with an FPU afaik - yay).

However, it does also point out that it wants 512mb ram (with a side-note that it does - just - run with 256). That said, I don't remember any P1 200MHz machines having that much, so, presumably, it may be possible to hack it to run on lower by sucking all the high-res goodness from the textures. Maybe.

hmmm, Privateer Gemini Gold!

 

[Exophase]

(considering that this time round we'll be using a chip with an FPU afaik - yay).

Don't get overexcited about Cortex A8 FPU, it's not pipelined

The IEEE-754 compliant FPU isn't, but the NEON unit is. NEON can handle scalar single precision floating point operations under its own ISA and it can run a subset of the VFP operations as well, meaning that a lot of floating point code compiled by GCC can utilize it out of the box (if the proper bit for it is set on the CPU). At first I thought this would be limited to simple move instructions but it also applies to some scalar arithmetic, but with some limitations. Having fast fmovs, fmacs and fcmps is probably enough to cover a lot of the functionality used in floating point code. The IEEE FPU on Cortex is good for double precision, though.

 

[ldesnogu]

The IEEE-754 compliant FPU isn't, but the NEON unit is. NEON can handle scalar single precision floating point operations under its own ISA and it can run a subset of the VFP operations as well, meaning that a lot of floating point code compiled by GCC can utilize it out of the box (if the proper bit for it is set on the CPU). At first I thought this would be limited to simple move instructions but it also applies to some scalar arithmetic, but with some limitations. Having fast fmovs, fmacs and fcmps is probably enough to cover a lot of the functionality used in floating point code. The IEEE FPU on Cortex is good for double precision, though.

My bad, I keep on forgetting NEON

But IIRC NEON only does vectored SP operations. What do you call "scalar"?

Also the NEON support in gcc is rather new.

 

[Exophase]

My bad, I keep on forgetting NEON

But IIRC NEON only does vectored SP operations. What do you call "scalar"?

Also the NEON support in gcc is rather new.

Scalar means single element, non-vector. NEON handles it, not just vector, although it is single precision only (but games have little business using double precision in the first place). The Cortex-A8 CPU is capable of issuing some VFPv3 instructions to the NEON unit, so GCC doesn't even have to emit NEON instructions in order for those floating point operations to be pipelined.

 

[Pickle]

My bad, I keep on forgetting NEON

But IIRC NEON only does vectored SP operations. What do you call "scalar"?

Also the NEON support in gcc is rather new.

Scalar means single element, non-vector. NEON handles it, not just vector, although it is single precision only (but games have little business using double precision in the first place). The Cortex-A8 CPU is capable of issuing some VFPv3 instructions to the NEON unit, so GCC doesn't even have to emit NEON instructions in order for those floating point operations to be pipelined.


So basically it comes down to is that we can use float and double operations as we would with any C++ program to our hearts content and none of it will have to emulated through software?

 

[Exophase]

So basically it comes down to is that we can use float and double operations as we would with any C++ program to our hearts content and none of it will have to emulated through software?

Sort of. Various more complex operations will still be done in software. Double precision will be handled in hardware, but on a slower (non-pipelined) IEEE compliant unit, so operations will take several cycles before another operation may begin. This goes for some single precision operations as well. Others will be issued on the NEON unit, which seems to have both a high issue rate and low latency.