   Best Platforms for Ultra-Quality Retro Game
  Hi all.I've been programming in various languages (and for various purposes) for a few years now, and I'm thinking of doing a bit of a side project involving making one or two games (at the very least, concepts, but with the intention to develop fully later) which are retro ideas but are more on the extreme side.Think breakout, but the most intense breakout game you've seen, in terms of busy screens & levels, intense particle effects and all that.What I want to know is, can anyone sum up a few platforms that I may have missed out on, which will provide good access to hardware but also a preferably quick startup, i.e. not having to learn too much of something too difficult. A list of comparisons would be ideal, so I can choose something that I'll be able to pick up without tearing my hair out, but which is still going to do the job.I don't want to state how much I'm looking for, technically speaking. I don't want you to ask me how many triangles I'm looking to render, because I don't know yet. I'd rather find out which would be most recommended based on the short description I gave - extreme, retro games, most likely 2D (but again, solutions for both 2D and 3D would help). If this means going heavily into (as a complete example out of the blue) HLSL for whatever reason, then that's fine, I just need to know how much benefit that would give on top of everything else, generally speaking.I'm open to engines and game builders, rather than core languages, but the emphasis is still on power and access from the point of view of someone with a good deal of coding time behind them.I've used things like AS3, Unity3D, C++, C#, WinAPI enough to be happy to use any of them.I just want to know I'm using the best solution for what I'm doing, before I begin this, because it's always a question that crops up for me.Also, if there's a sticky for this topic, please direct me to it, and I'll be happy to remove this!Thanks!PS - I also thought this'd just be an interesting topic... it's not all that urgent or anything!   
  As you have some experience with various languages etc, just use what you are comfortable with.If you have OpenGL or DirectX knowledge, go with one of them. For 2D you'll quickly be able to  abstract away the technical parts into a sprite class or something like that.   ;  Thanks for your reply.That's what I've done to date. However, it quickly gets to the point where I can't freely throw sprites around in that 'extreme' way I talked about, and I have to do some optimisation. But my code doesn't really need optimised itself, it's more the methods I'm using. Back when I used OpenGL, for example, I tried using point sprites for particles, but that provided little improvement.I suppose one of the questions I have is, what am I doing most wrong? Is it that I need to start moving everything into shader languages and be at one with them? Or is that a myth?One of the things that bothers me about the OpenGL front is distribution. I don't want to just produce yet another experiment. I'd like for the game to be available for download or something like that, or ready as a portfolio piece, with a reasonable frontend and possibly installation package.This brings me back to what I liked about Unity3D. For those of you that have used it, it handles all these things quite well, but I don't know if I want to use it to produce the types of games I described, because it feels as though Unity is going to slow that (and me) down in the long-run, and I do also want to put my own programming stamp on it by building more things on that level, not just scripting the last little touches where absolutely necessary. I've never used Processing, but I get the feeling it'd suit me more than Unity for this type of project. This is why I'm asking you guys, though!   ;  The iPhone crowd will likely eat that stuff up. GameLoft is making crazy amounts of money doing basically less.   ;Quote:Original post by industrionThanks for your reply.That's what I've done to date. However, it quickly gets to the point where I can't freely throw sprites around in that 'extreme' way I talked about, and I have to do some optimisation. But my code doesn't really need optimised itself, it's more the methods I'm using. Back when I used OpenGL, for example, I tried using point sprites for particles, but that provided little improvement.Really I doubt you are encountering a fundamental limitation in OpenGL - after all, some very graphically impressive games have been made with C++/OpenGL.It is likely that there are at least a few significant optimizations to be made in the way you handle particles... how are you drawing them? (can they be grouped more efficiently? consider offloading some work to the GPU as a shader?), how many are you drawing? how complex is your algorithm for updating their position?A quick search turned up http://realtimecollisiondetection.net/blog/?p=91 with a few suggestions.Essentially using some third-party framework is not going to offer speed bonuses due to any innate low-level "fastness" but by in some sense actually doing "more work" to gain logical efficiencies, built on top of a more low-level system like plain C++/OpenGL.A very basic example is something like a culling step making rendering faster. For particles it might be something like rendering a group of them to texture and drawing as only one poly.Another key point is to profile your code - you need to know exactly where it spends its time and what parts of it are causing slowdown. This is the only surefire way to optimize pragmatically.   ;  Yeah, I should probably profile it. I've done all the culling and grouping stuff. I know (or at least I'm under the impression) that you should, for one, group particles by texture used, so as not to constantly rebind textures. Things like that, I'm okay with. Moving stuff to the GPU is where I'm not so great, though. I find it hard to find good practical examples of things like this, with a walk-through of the shader as well as just a dump of the file on some thread, saying "this is my shader program".   ;Game Maker is excellent for 2D games. It's also cheap - $25 last time I checked.   ;  Usually if you have performance problems with 2D sprites, the two most likely causes are fill rate and state changes. If you have a ton of large sprites and are running in a high resolution, each one of the million+ pixels on the screen may have dozens of writes per frame and this will bog down the video card. To test whether this is the cause, try running in a low resolution. If the frame rate improves then fill rate is the problem. In particle systems, it's common to see textures where the particle occupies a small area in the middle of the texture and most of the sprite is empty space. This empty space is still blended into the frame and eats up fill rate. If you can make the polygon half the width/height, you'll reduce fill rate usage by 75%.State changes are things like changing the texture or shader. This is a time-consuming operation on the video card. A common beginner mistake in sprite rendering is to set the texture for each sprite and draw them one by one. If you set the texture/shader once and then draw every sprite that uses the same texture/shader in one batch, you can get a dramatic performance improvement. Modern video cards are optimized to display 3D models with thousands of polygons each, so the best performance in 2D is found by batching thousands of sprites and drawing them all at once. If you're using OpenGL immediate mode, switch to vertex arrays or VBO. (IIRC OpenGL ES on iPhone doesn't even have immediate mode)   