Available technologies and versions?

[kaprikawn]

I'm trying to learn game development at the minute and I'd like to target the Pyra, but my googlefu is somewhat letting me down in trying to pinpoint what technologies I'll have available to me.

At the minute I'm just learning the basics with C++ and SDL2 and making good progress. My goal is to make a 3D game playable on the Pyra, I realise this may be too ambitious and am willing to reign in my expectations and fall back to a 2D game using C++/SDL if necessary, but if I can make a 3D game, what technologies will be available to me?

From what I can make out, the GPU/driver is capable of OpenGL 2.1 or OpenGL ES 2.0, given that choice I'd probably go for ES. Is my assumption correct with regards to what the Pyra supports?

Also, what is the status of later versions in the categories of 'Supported', 'Possible', 'Unlikely' or 'Never Going to Happen' with regards to the Pyra supporting OpenGL 3.3/4+, OpenGL ES 3 and Vulkan?

And lastly, what are people's thoughts on SDL vs SFML? I assume the Pyra will support both, but I think that someone (Notaz?) released a version of SDL that specifically targeted the Pandora IIRC, would this make sense on the Pyra and is it likely to happen? Or is that idea somewhat redundant on the Pyra, and the stock version will be just fine? If a specialised version of SDL is possible for the Pyra would it make more sense to target SDL? Or if the stock version of either is fine I assume it just comes down to personal preference as to which I should use.

Thanks in advance

 

[ible]

i'm also very interested in understanding what's possible, 3d wise, once the driver gets working.

right now, i'm looking into this minecraft engine:
https://github.com/fogleman/Craft
which is super nice (runs with real low CPU usage), but requires shaders and what not. but i guess it's possible (see https://pyra-handheld.com/boards/th...g-competition-rules.73122/page-3#post-1266393 for another mention), but i'm not sure if it's become anything.

 

[Xcl4m4t10n]

Hello AVGN!

 

[Pocak]

OpenGL support on the Pyra will be the same as on the Pandora. That is, OpenGL ES 1.1, ES 2.0, and some of OpenGL 1.x via glshim. The newer versions you mention are clearly in the 'Never Going to Happen' category.

Pyra's SDL will have the same additional features as Pandora's. I think these only relate to scaling and vsync. If you make your game run at native resolution then these will be unnecessary. So you can go with what's convenient for you (I haven't used SFML or GLFW, so I can't comment if they're any good). Or perhaps ponder whether rolling your own engine is the way you want to spend your time.

Looking at Craft, it's targeting desktop OpenGL 2.1, but refrains from using deprecated features—the kinds of things that were cut from OpenGL ES. So perhaps it could be converted to ES with small effort.

 

[mjohansson]

If your just starting out I wouldnt worry about openGL 3 and onwards, 2 is all you need for shaders, if your planning on going far you can always go further with more advanced stuff later you dont need to start with the most difficult. Id recomend starting from the beginning with guides like NeHe and LazyFoo, really you can make games with the most simple tech if your not pushing AAA graphics, and creating AAA quality content takes forever and a little longer still, its not impossible but if you wanna do that level then start looking at Unreal Engine instead, otherwise keep to the simple tech and forget about Vulcan, thats for the AAA devs.

 

[levi]

OpenGL support on the Pyra will be the same as on the Pandora. That is, OpenGL ES 1.1, ES 2.0, and some of OpenGL 1.x via glshim. The newer versions you mention are clearly in the 'Never Going to Happen' category.

Does that mean no shaders on Pyra? Granted that'll depend on working 3D drivers, working glshim and so on. I don't really know my GL versions from my elbow here.

 

[mjohansson]

ES 2 supports shaders.

 

[kaprikawn]

OpenGL support on the Pyra will be the same as on the Pandora. That is, OpenGL ES 1.1, ES 2.0, and some of OpenGL 1.x via glshim. The newer versions you mention are clearly in the 'Never Going to Happen' category.

Pyra's SDL will have the same additional features as Pandora's. I think these only relate to scaling and vsync. If you make your game run at native resolution then these will be unnecessary. So you can go with what's convenient for you (I haven't used SFML or GLFW, so I can't comment if they're any good). Or perhaps ponder whether rolling your own engine is the way you want to spend your time...

Thanks, that's really useful. My thinking behind rolling my own engine rather than using middleware is that I want to gain an understanding of how things work under the hood. I don't want to use code that I don't understand, kinda like writing HTML in a text editor before using Dreamweaver (or whatever people are using these days, I still do my own HTML so am not familiar with the tools). If I write it all then I know exactly what it's doing. Although I may reassess that position when I'm done with the tutorials I'm following and actually start my own project.
[doublepost=1460804513,1460804287][/doublepost]

If your just starting out I wouldnt worry about openGL 3 and onwards, 2 is all you need for shaders, if your planning on going far you can always go further with more advanced stuff later you dont need to start with the most difficult. Id recomend starting from the beginning with guides like NeHe and LazyFoo, really you can make games with the most simple tech if your not pushing AAA graphics, and creating AAA quality content takes forever and a little longer still, its not impossible but if you wanna do that level then start looking at Unreal Engine instead, otherwise keep to the simple tech and forget about Vulcan, thats for the AAA devs.

I won't claim to know OpenGL, but wasn't there quite a big jump/change in tech between 2.1 and 3.3? While I appreciate that I can learn stuff from learning 2, if it's not how people are writing code these days wouldn't it be better to go for 3 given the choice?

 

[Red Ring Rico]

There was and wasn't a big jump between 2 and 3. It's just that the fixed-function pipeline way of doing things is not supported in OpenGL 3.1 and beyond if you create a core profile. Instead of using glBegin/glEnd to do your rendering, you submit batches of primitives via glDrawElements, which has been around for a while. The main difference is that OpenGL 3 supports geometry shaders, with OpenGL 4 supporting tessellation shaders as well. There are of course new functions that were added in 3 and 4, but for the most part whatever you do in 2 (desktop or ES) will be able to be carried over to 3 and 4. Just be aware of the deprecated functions as you go and you'll be fine if transitioning to a later version is a concern.

 

[mjohansson]

I just looked at Vulcan recently and felt it was like getting a bag og bricks slammed in my face, if I had encountered that first instead of the easiest openGL tutorials I would have called it a day and never looked at coding ever again, I just wanted to point out you can do a lot with the basics and its an easier start, whatever you do just dont give up but know there are always alternatives and just pick the ones that works for you on a comfortable level. If your not writing an engine in the class of Unreal Engine your not gonna do anything wrong, in the end if the program works what else matters?

 

[levi]

Well, Vulkan (note spelling) has been out for less than a year, and those tutorials take time to write and refine. But perhaps it's also that Vulkan is designed to run closer to the metal, while OpenGL is designed around simpler more user-friendly concepts.

 

[Silent-Hunter]

I thought Vulkan was just basically OpenGL 5?

 

[Red Ring Rico]

Vulkan is more like the Glide and PowerVR APIs from the mid-to-late '90s. By that, I mean it's a low-level API, yet cross-platform and cross-vendor.

I really like Vulkan, but haven't been able to dedicate much time to it.

 

[Rockthesmurf]

Writing your own 3D engine from the ground up in GL/GLES 2+ is certainly a rewarding experience, but it includes a huge number of dependencies, doing it all yourself again is rewarding, but will take a long time (not so much the coding time per se, but learning all the concepts required). If you don't want to rely on existing libraries/middleware and want to do everything yourself, this will include:

• Writing vector, matrix, quaternion methods
• Implementing a 3D physics engine (assuming your game requires some sort of physics simulation)
• Writing texture importers
  
• Getting models from your 3D package (blender?) into game, which typically involves parsing large data files, spitting out a custom data file, working out what to do about materials, shaders, instancing, triangulation, tri-stripping, etc.
• Writing a pipeline that will allow things to render (sorting objects correctly, frustum culling, setting material state, setting correct shader based on what is being rendered)
• Writing shaders (or perhaps writing an ubershader which is then compiled for each material your scene in blender uses)
• Considering what you want to do about lighting (loads of solutions here, but you need to take the above two points into consideration with your lighting)
• Writing key frame transform code for animation (if you want any animations that aren't hard coded)
• Writing skinning code to run on the GPU (if you want skinned characters or other elements in your game)
• Writing camera/viewport code for viewing your scene
• Implementing IO logic for keyboard/nubs/etc. so you can interact with your game
• Working out how to architect large amounts of code (something that isn't really considered early on, I guess it doesn't even mean anything early on, but it soon because quite a highly valued skill to have)

For someone that understands all the concepts well, it is still a reasonable sized task, but certainly very achievable. For someone that also doesn't understand a lot of the concepts (matrix maths, rendering pipeline on the engine side, graphics pipeline in terms of GL state, file formats for models/textures, how hierarchical bone animation works, how skinning works, etc.) then there is a long and complicated road ahead! This isn't meant to be a post to put your off in the slightest, it is really just trying to give you a little food for thought in terms of what you will need to know, where some research maybe required, etc.

The vast majority (and I mean vast) of projects which attempt to do the above will never be completed - the majority of projects that get completed are ones which are pretty small and achievable. My advise would be start with something small and as simple as possible, finish it, and then move onto the next thing (where the next thing is a little more ambition). Rinse and repeat this a number of times and you end up working on cool projects and understanding all the bits in between. Certainly 2D is a lot simpler than 3D, a big reason for this is that the maths required for 2D is already known by a lot of people, the physics can be pictured and worked out in your head, the rendering is simpler, a lot of more advanced concepts don't typically need to be considered (shadows, lighting, normal maps, etc.)

What ever you choose, good luck, I'm sure it'll be a lot of fun!

 

[ible]

small projects do tend to get done a bit faster... and accomplishing something always feels good, so it's nice to have smaller projects in addition to the big ones.

here's a 3d engine which you get to mess around a bit with your own viewing algorithms and physics, but there's still a lot already there for you to use: sparrow3d. i implemented bullet physics in it a while back, but i haven't been keeping it up-to-date, so i have no idea if it compiles...

i'm modifying fogleman's Craft right now, to see if i can still get some decent FPS (with integrated graphics) with some more complicated geometries.

 

[kaprikawn]

Writing your own 3D engine from the ground up in GL/GLES 2+ is certainly a rewarding experience...

Interesting post, thanks for your input. I'm by no means ignorant to how much work it'll be, but I'd much rather do everything myself and gain an understanding of how everything works as opposed to using Unity/Unreal etc. and have that obfuscate what's going on behind the scenes.

I do a lot of scripting at work and consider myself rather good at it which I know is a different discipline in many ways. But what I do know from that is using other people's code verbatim without knowing how it works and what it's doing is rather redundant, like the coding equivalent of consuming empty calories, it may get the job done but it's doing you no good.

Making a game isn't really my end goal, learning about programming and game making is, I'd like to be able to contribute to open source projects eventually.

If I do make a 3D game I'd like it to be of a similar quality to Starfox on the SNES, that's my initial aim. The reasoning being that I can not have to worry too much about the complexity that may be introduced by things like texture mapping, lighting and the like. But I do want to use forward-thinking technologies so that I don't have to relearn the basics when I do start introducing more advanced concepts, I want something I can build on which is why I don't particularly want to use early OpenGL versions. OpenGL 2 may be fine for my requirements now, but it's a technology that is pretty much on it's way out. Whereas something like OpenGL ES 2 seems to be a bit closer to more modern techniques and I believe that will give me a better springboard to my eventual goals.

We'll see how it goes, it's almost certainly the case that I'll have to start out with something 2D. But I'm rather envious when I see other people releasing stuff and I can't do the same, I want to be in that club whereby if something isn't working for me then I just work on it myself. I've got that open source itch. I just need the means to scratch it. Besides, I just really love coding and just want to expand my horizons.