I’ve spent a rather long time trying to get a solid direction going in terms of setting up a back end asset/entity management system. I didn’t want to build one myself. It’s a pain in the ass, and a major time sink. I’ve been sniffing around looking for other frameworks to handle this for me. This week, I’ve been giving the Citrus Engine a whirl, but there have been a few rather important flaws that have popped up.
- When entering and exiting fullscreen mode, Citrus (and implicitly, Starling), would crash due to a loss of Context Error. It’s VERY frustrating for me to chase down bugs in someone else’s framework, and after a good two days of spinning my wheels, I couldn’t come up with a working solution. Too bad. Citrus was looking very promising.
- Starling also doesn’t seem to want to scale when Stage.displayState is set to StageDisplayState.FULL_SCREEN_INTERACTIVE. It locks the render area to the stage’s predetermined viewport size. The fix has been to increase the viewport’s dimensions to full screen dimensions, but that is NOT what I want to do. I want the resolution to remain the same (1024, 576 for example), but to have the rendered image scaled to fill the screen. I’m done trying to get this fixed. It’s a TERRIBLE fault in Starling’s design.
- Starling also has no support for functionality similar to Flash’s Sprite.graphics.lineTo(x, y) drawing. There are some bandaids offered by other developers, but they lack a means of transforming a texture used to fill a given polygon. What’s more, if you want to have a texture tile in Starling, it CANNOT be from a texture inside of a texture atlas. It has to be in its own separate Texture. THIS IS CRAZY! The whole point of using Starling is to utilize the hardware for maximum efficiency, and texture atlases are a large part of how you accomplish this feature!
- I can’t seem to find very good information on using Starling for games that aren’t small, casual titles. What I find are articles on “How to make a gem puzzle” or “Angry Birds clone”, which all require a single TextureAtlas to contain all graphics. If I’m trying to make a game that essentially looks like this, I’m going to need a hell of a lot more than a single texture atlas. Where on Earth do I even start in setting up something to handle this?
If anyone has any practical solutions to these problems, please let me know. Otherwise, I’m back to using Nape physics and my own proprietary image management for Conjurer.
I don’t use Starling myself, because Adobe’s GPU cutoff ironically ends on my Radeon 2400. This annoyed me for over a year because I can program in Unity on the same 2007 iMac to display 1,000,000 triangles with a view distance of 50 virtual km. I think I could handle the blitting requiring for Starling…
I do like Flash/Adobe AIR, though – nothing really trumps it as content generation to final deployment workflow. I know you opted to switch to LibGDX – I looked into it as well (but it has its own set of caveats).
However, if other people have similar issues, they might find these answers useful. In that spirit…
1) Your loss of context error is fairly common in OpenGL programming – you have to save the context. If that is not happening, Stage3D is likely at fault first, then maybe Starling, then maybe Citrus and then maybe you. I recommend examining the documentation to see which API is responsible for saving contexts. There might be a boolean in a constructor call that needs to be set to true, for example.
2) Your second problem, regarding scaling, is also an OpenGL issue. By default, nowadays, graphics drivers (ie. the low level stuff from AMD/ATI, nVidia, Intel, Apple) will select the native resolution of your display. Most graphic engines will respect that. This is a TFT/LCD/LED thing – do not fight it. All other resolutions are just interpolated scaling, with associated filtering (think antialiasing) done by the display itself. What you need to do to get a virtual low-resolution is render-to-texture. This means you redirect all your on-screen graphics to an off-screen texture. This is done every frame. Once the texture has been composited (completely drawn offscreen), you display it on-screen. The off-screen texture can be any size (smaller in your case). You then display it to a higher resolution on-screen display by stretching it using traditional texture scaling. You can switch off texture filtering (bilinear, trilinear, anisotropic) for a pixel-art look.
3) Another OpenGL issue. Starling is sort of a blitting engine. This means all it does is take textures and whack it to the screen. It lacks all other GL stuff like polygons, lines and so on. At best you have to draw lines into textures and display the resulting textures. However, the Starling draw context exists separately from the traditional Flash display list. So you could draw lines in the normal Flash display list which should appear atop the Starling display. However, this means they could not be interleaved (depth sorted) with your Starling graphics. What I recommend is this – check what your game really displays. If you are doing more polygon or GL stuff – use Away3D. You can always display sprites as textures using Away3D. Do not use an inappropriate technology – square pegs, round holes.
4) I understand your concern about the texture atlas stuff. Trust me, you ain’t seen nothing yet until you try to create graphics for Unity’s bizarre UV mapping system. What you have is a dichotomy between the art you (or your artists) are trying to create and what the engine is saying it will accept. That scene you refer to only has 8 small moving sprites, 1 large moving sprite, largely static backdrop and probably animated water. The other elements (HUD, scoring) are ancillary for now. Create 1 texture atlas for the big guy, because he’s big. Keep your atlas at 1024×1024 or 2048×2048. If you need to do not be afraid to split the atlas into more than one (idle, attack, angry,…) The small guys are just one character, so one atlas. Here is where you likely will get frustrated. People will tell you to combine the bat character with the HUD and score elements. You could do that, if you are using external tools like Texture Atlas, Shoebox and so on. Do you need to do it? Not really… GPU tech does not rely on you popping 5 big textures onto the bus – you could also pop 50 small textures. It will still work – just load the textures well before you display them. In other words – do not load-and-display and expect 60fps. You must load the textures at level start or during some sort of lull in the game. Breath. Display. You must defer texture loading from display by some margin – to ensure that all textures have been uploaded to the GPU and processed fully. Particle effects are their own thing – always leave enough margin to display sufficient quantity of them. By the way particles work according to a formula (which I forget now – but it’s something like emit rate * number of particles). So you can control the exact amount of particles per frame/second for any particle system.
Anyway – that’s all… I guess. Good luck.
Good comment. Thanks for the points. I’m making the push to Unity as well, especially after hearing news about their upcoming 2D tools.