New Linux Game Handheld?

[xav1r]

...oh, and if anyone knows, how come none of the big commercial handhelds, the DS, the PSP, etc are OpenGL ES enabled?

[Ex-Cyber]

...oh, and if anyone knows, how come none of the big commercial handhelds, the DS, the PSP, etc are OpenGL ES enabled?

OpenGL ES wasn't really established when PSP and DS were developed. I think the spec existed, but it didn't have any kind of widespread support.

[Svartalf]

...oh, and if anyone knows, how come none of the big commercial handhelds, the DS, the PSP, etc are OpenGL ES enabled?

Heh... As was stated previously the spec wasn't there. Moreover, it's not been until recently that people figured out ways to make GPUs that're reasonably capable for this sort of stuff into handhelds. Remember...GPUs are typically power hungry, heat dissipating beasts.

The PSP and DS wouldn't have had more than about 1-2 hours of operating life, if that, and would have gotten WARM to the touch if you fielded the level of tech we're talking about right now. As it stands, you still need roughly 4-5 times the battery capacity to make the Pandora run roughly as long as the PSP does.

Rest assured...the next generation, of which the Wiz and Pandora belong to, HAS the tech in question in it. Keep in mind, though, you won't be able to tinker with code unless you work for one of the big boys if you get one of their next-gen units. It's counter to their DRM based model and you have to hack around their frameworks to get even basic homebrew to work. Don't expect the homebrew options with those handhelds to have ANY ES driver support for them.

[Dragonlord]

I think that's the reason. The DS has a self-baked OpenGL which works to a large degree like OpenGL 1.1 but has some differences. I can't now talk of my own experience since I did not touch DS-Deving yet since I wanted to first get this project done before messing with my trusty DS.

What goes for DirectX vs OpenGL...

DirectX comes with an SDK which is though mostly only a lump of documentation ( hard to use though ) and tons of demos/samples and some tools. You do not need this entire beast to develop for directx since you need only the headers and libraries which are inside the SDK.

Now what goes for OpenGL you need nothing... at least on a Linux system. What you need is "GL/gl.h", "GL/glx.h" and "GL/glext.h" ( last one if you want to use extensions without defining the stuff yourself all the time ) as well as linking to -lGL. Once that's done you are ready to do OpenGL. In contrary to DirectX OpenGL is driven by a state machine approach which means that you program OpenGL in a procedural way instead of a pseudo-object way as directx. Just imagine OpenGL being a box with tons of switches and buttons in front of you. When you press the render button it spits something out depending on the state of the switches. Hence you flip the switches around until they are right and then you toss out a render repeating the process. DirectX hides this to some degree behind your back which is why people can get a bit confused on how the two relate. Definitely have a look at OpenGL tutorials ( Humus3D for example is a nice place... NeHe only for the real basics... got into crossfire on gamedev for aged principles <.=.< )

EDIT: Rofl... got insta-posted by Svartalf :P

[Svartalf]

Ah ok. Now, more noob question alert. So is the cortex the most powerful mobile processor right now? I thought ARM licensed their cores to TI for it, is that right, or does TI make all the processor hardware required? I'd like to know how does that work.

Cortex-A8 and A9 are licensed cores, yes. TI and Qualcomm are currently the only licensees (with silicon even remotely out)- and Qualcomm has made an even more aggressive power management design respin of the core. The OMAP3 is a SoC with an A8, a next generation core of their DaVinci DSP line, an Imagination Technologies PowerVR SGX core, and a few other needed component cores. TI fabs the whole lot in their Richardson, TX chip fabs and then sells 'em to handheld device and cell phone makers. There will be, I expect, some takers on Qualcomm's Snapdragon, as it uses AMD's GPU, has even more specialized power management (you can power pieces of the CPU down as needed instead of just the whole CPU core, for example...) specifically designed for mobile phone use.

[edit]

As for the OMAP3 being the most powerful...

The reason being is that, while ARM has an even more powerful A9 core available and more powerful than that on the way, only TI has taped out with devices to be bought and put into product right at the moment. Nobody else has A8 silicon in production quantities right at the moment and nobody's got A9 silicon even close. (It's my understanding that there's currently 3 or 4 A9 licensees right now, no details, per se, on whom they are right now. But, having said this, they've only licensed in recent times, which means a 6-12 month window from NOW on when the A9 stuff might begin to start showing...) Anything else is using a MIPS R4000 class CPU at low clock because it's cheap and very low power (Think those digital picture frames...) or an ARM 9 or ARM 11 core.

And also, I've been browsing the opengl site to find out more about it, and learn how to program for it. From what ive browsed, there isnt one specific SDK, as in for example, the directx one, that you can download from the opengl site, but many different solutions you can get anywhere else instead. So where exactly is opengl? In the gfx card drivers?? In the opengl32.dll on windows? what do i need to know that opengl 2.1 for example is available on my computer to program for it?

It varies from machine to machine and will be in all sorts of goofball places in the filesystem, unfortunately. You won't be able to ask the system if it's there other than to try to load the official .so/.dll name and if it fails, it doesn't have it.

The "SDK" as you describe it, is more of an Application Programming Interface, of which there's two dominant ones right now. Direct3D from DirectX and OpenGL. The drivers are a simplistic beast, really, understanding how to present processed command streams to the GPU's processing units.

Think of it in terms of a specialized OS, coupled with a specialized programming language to express what you want to have rendered to the screen done by an even faster, dumber idiot than the CPU. Keep in mind, that's somewhat of a poor analogy, but it's a decent enough one for this discussion. It's the fact that it sort of works that way that people can do "General Purpose" GPU operations, submitting specific supercomputing-like requests for non-rendering work to the GPU to be done VERY fast when compared to doing it on the CPU.

Direct3D views the world in a slightly different manner than OpenGL, but intrinsically, they accomplish the same things- so it's doable to move from one to the other or make a workable rendering layer for both within a game.

Now, in the mobile space...heh...Direct3D is largely a never ran. Most people use an ES 1.1 or 2.0 driver in their devices because D3D, while it was "nice" is hideously BLOATED in comparison to ES 1.1 and 2.0 in API edge size and the code you produce even with D3D mobile tends to be bloated. Funny that. With mobile devices, you can't just drag a desktop paradigm along for the ride and expect it be "okay". It's part of why WinCE/Windows Mobile hasn't taken off like MS thought it would. The bulk of mobile devices that have 3D will have ES 1.1 and 2.0 at their disposal and there's a .so or .dll that you link against. In the mobile phone space, there will be a Brew or Java "Jar" that will tie in against the system .dll or .so accordingly.

[xav1r]

Hmmmm, qualcomm, are they the same manufacturer of the BREW mobile platform, or API, im not sure which one? One thing i dont particularly like of them is that they seem to have a policy of charging you for everything that involves their products. A while back i wanted to create a little mobile app, basically a simple modification for the wolf3d port for the n60 devices. I looked into BREW, and in order to do use their SDK, i had to pay for a subscription, pay monthly fees, be approved by a reviewing board, etc. Whereas on the competition, namely j2me, i only had to download the SDK, and program away.

Interesting explanations, thanks Svartalf and DragonLord. Now i understand more clearly.

[Svartalf]

Hmmmm, qualcomm, are they the same manufacturer of the BREW mobile platform, or API, im not sure which one?

Yeah...that Qualcomm...they also make silicon SoC designs that're typically used by Sony, LG, Samsung, and others that do CDMA and G3 phones on the high end of the spectrum. I've got a piece of their silicon I cart around every day on my belt... They're the ones that actually came up with the carrier technology we're currently using with CDMA and one of the two G3 and G4 modes of operation.

And, Brew's more of a platform than just an API. Managed by Qualcomm and Verizon, Sprint, and other CDMA crowd providers... The coding/API part is an ersatz variant of the Java J2ME edition before Sun got serious about that sort of thing that the CDMA crowd came up with so they'd have cool stuff for their phones before the GSM/G3 people got there.

One thing i dont particularly like of them is that they seem to have a policy of charging you for everything that involves their products. A while back i wanted to create a little mobile app, basically a simple modification for the wolf3d port for the n60 devices. I looked into BREW, and in order to do use their SDK, i had to pay for a subscription, pay monthly fees, be approved by a reviewing board, etc. Whereas on the competition, namely j2me, i only had to download the SDK, and program away.

You'll note I don't do Brew if I can at all help it...

The reasoning for all of this is that you can't submit stuff for use within a Brew phone because the phone network operators want a cut of the money, etc. and want to quality control it all. While there's QUITE a bit of money to be had in that space, if you thought the consoles were controlling and scheming...

Interesting explanations, thanks Svartalf and DragonLord. Now i understand more clearly.

You're welcome.

[xav1r]

And to think that when i read Carmack's praises of the BREW platform when id was promoting Doom RPG, saying how it was a window of opportunity for independent startup game developers, then rushing into the BREW site to get my kit and get started, and then finding out that i have to sign up and shell out like 400$ just to be able to program anything, such a bummer.

[Dragonlord]

"ersatz variant"

... Wait a minute... where are you from, boy?

[Svartalf]

... Wait a minute... where are you from, boy?

The States... Been living in Texas for the last 2/3rds of my life, but was born and grew up in Oklahoma (Heh... Garth Brooks was a bench warmer on the football team... ).

Having said this, all sorts of odd idioms and English words have accreted on my person and I seem like I ate a couple of differing dictionaries over the years...

I use words and terms that suit me, not always the ones that come from the areas I've lived in.