Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About anothergol

  • Rank
  1. anothergol

    Best engine for me?

    Yes, I figured that out in Cocos2D:x, however it's unclear to me if its "sprites" are designed to be the real entities on-screen, or if they can be re-used on the fly.   That is, say in the first cycle of a game you have an enemy & the player on-screen, and in the second cycle, the enemy has disappeared, while the player is still there. The way I'd do it, I'd pre-create a tank of reusable (Cocos2D) "sprites", and during the first cycle, the enemy would use sprite#1 to draw itself, and the player would use sprite#2 to draw itself. Then in the next cycle, the enemy wouldn't be there anymore, and the player would now use sprite#1 to draw itself.   But I don't know if that's a good use of Cocos2D's sprites, if there is a big penalty in changing a sprite's texture coordinates, and possibly its Z-order. In any case, it's the idea that an entity in the game is tied to a graphic object, that I don't like (I mean, those entities are none of the engine's business). And yes, I would probably end up writing motion stuff myself, but I wouldn't tie them to graphical objects, but to the game's concrete entities.     Another example, say I want a tilemap, with 3 layers: -the background (decoration parallax layer) -2 foreground "solid" layers, tied together, only separated to overlap tiles for more complex results Now let's imagine I want to rotate the 2 front layers alone. The way I'd do it, would be to first render the background map, and then render the 2 front layers in a temporary texture, and then rotate/blit that texture over the background. I read about Cocos2D:x working exclusively in "nodes", and I couldn't figure out how this would work. But it's kinda critical, because if I want the rotated map to have antialiasing, the tiles can't be rasterized rotated, it would certainly go wrong on the edges. The map has to be fully rendered first (& in this case, the 2 front layers rendered to the same texture), and then the result can be rotated. But again, this is something I could figure out how to do with those "simple" SDK's, but with Cocos2D it looks like you have to fit this inside the node system in some way.   There's already tilemap support in Cocos2D:x btw, but reading the description I'm not even sure how it's implemented: In the screenshots section, the first one seems to hint that each layer is rendered to a texture. But the description doesn't hint that. And "Each tile will be represented by an CCSprite" can mean several things. But I assume that it's not really creating a sprite for each of the map's tiles, only the visible ones(?). And even here it doesn't make much sense to me.   I've also read about using a fragment shader to render whole maps, but it's not even something I'd want to touch, on top of having to learn a new language. Which is kinda why I'd rather pick the engine that has a philosophy that I understand but is also done efficiently. Because having to fix things myself in someone else's code will probably end up worse than having to do it from scratch in the first place.
  2. anothergol

    Best engine for me?

    I'm still looking for the best engine for my needs, I checked A LOT of the available SDK's out there, & while I still don't know what I want, I now know what I don't want.   -coming from over 20 years of pascal, I didn't even know what C# was, I naïvely thought that it was what C was to C++. But ok, it's managed code, no thanks, I like to know what's happening behind my back. Also coming from Delphi, I'd rather stay away from that horrible .NET (well when it came to Delphi it was a horrible experience). So I figured out that C++ was probably my best option. Sure I'll have to learn it, but the concepts aren't that different from pascal, it's just the language that changes.   -I thought that every SDK out there now worked the same, and that I was just too old for this. But no, things like XNA/Monogame or SFML still work exactly the way I like: a game loop, blitting stuff, full control. So that most likely excludes Cocos2D:x for me, because it seems that it can't be used that way, it's using that same concept as in Unity: movable objects, events, etc. I really don't understand where this concept is coming from (Flash maybe?), nor how a game is made this way. I would really like to understand, but when I think of the not-so-complex platform games I was making 20 years ago, I really can't imagine all of the stuff in it being objects that belong to the graphic engine, I can't picture this working. I can understand why a game engine has to buffer commands, it's the graphic cards that require batching, but I don't understand why a game engine wants to control animation & stuff. To me a game is: a game loop (nowayays the loop advances in variable steps, that I understand, screen refreshes are not a constant anymore), processing input, doing game logic, rendering the stuff. All in clear blocks.     Problem is that the "simpler" SDK's out there are generally the least supported. Looks like with Unity there is a TON of stuff to look at. With Cocos2D:X there's support for a couple of great things.   Anyway, C++ & "non-event-based" SDKs already limit my choices a lot, if I also select the ones that have native support for the Tiled map editor: -SDL -Allegro (these 2 I remember from a long time ago) -indielib -SFML I've read that SFML (edit: neither SDL nor Allegro apparently??) doesn't do sprite batching by itself, too bad if it's true because the API looks simple. But I'd rather avoid having to dig in OpenGL myself, on top of having to learn a new language.
  3. anothergol

    Finding the right sprite "bank" tool

    I started reading about how sprites work in Cocos2D:x, and something didn't feel quite right to me. When I was making games, what I called sprites were just the images, and painting them was a different part. Like, during each cycle, I would paint every sprite on purpose, the sprites were just the images, not the objects.   In Cocos2D:x, it seems that sprites are more like hardware sprites of an old console, they are the objects themselves. Looks like each sprite holds its position, scaling, etc, and "lives" by itself. Not really a concept I like, to me the real "entities" should be things like the player's character, enemies, etc, which are responsible for painting themselves, whether it's from 1 or several sprite images. But linking them to other "living" entities seems like a weird concept, one that's linked to old hardware.   But maybe Cocos2D:x also has support for programmer's responsability to paint? Or is it a common thing to create a "sprite pool" and steal them in order to paint randomly, like in 1 frame an enemy uses Sprite#1 to paint itself, and in the next frame, where the enemy disappeared, that same Sprite#1 is assigned another texture/rectangle, so that the player can use it to paint itself? That would make sense, but that's not really how I understood Cocos2D:x's normal handling of sprites.   Afterall, even just due to z:ordering, using MonoGame I wouldn't let an enemy paint itself by sprite batching directly, I would more batch its commands myself, z-sort all this once everything has been processed, and then spritebatch the sorted array of commands. So is this "array of commands" what sprites are in Cocos2D:x?
  4. anothergol

    Finding the right sprite "bank" tool

      Ah, I hadn't read that in its features list. Sounds like an option then, thanks for the info. Perhaps it's then everything I need when combined with PhysicsEditor, assuming that it allows more than 1 path per sprite.   Yeah I've read in depth about all those engines, and I keep hesitating. Mainly between Cocos2D-x and Monogame. So many choices.. I even gave another try at Blender to see if I couldn't get into 3D (afterall, more time spent on models, but less on animation) and I still can't figure out any of it.
  5. Hello,   In another thread I was asking which language & API I should go for, coming back to games after 20 years (& knowing Pascal, which is more or less dead, for games, by now). I've figured out that the best, since I'll have to learn a new language anyway, would be to check which tools are available out there, & to go for whatever API's they support.   20 years ago I had my own tools, and I'm looking for similar existing tools. I had a good tilebank+tilemap editor, and here it mostly seems to be covered (on the paper) by the "Tiled" map editor, and more. It even seems to have solidity paths per tile (making me wonder if I couldn't also use it as a sprite bank tool), I didn't have that luxury back then. Also seems popular & supported, so this seems covered.     On the sprites side however, I'm finding a lot of simple texture packers and a lot of complex 2D animating tools (Spine, Spriter), but nothing "in-between". I don't need 2D animators (yet), however to me the bare bones of a sprite bank tool (of course back then I didn't need texture packing as nothing was 3D-accelerated, but I still had my sprite manager tool) are:   -sprite centering. Apparently existing tools (except Shoebox apparently) expect you to center your sprites inside a large blank rectangle. True that they will get rid of the emptiness anyway, but it's hard to predict your largest bounding box IMHO. Do people really align/center sprites by code?   -collision/random rectangles. My tool had collision rectangles, the complex animating tools seem to have all this in free form, but the simple packers seem to have absolutely nothing here. Other kinds of points/rectangles/zones are handy when it comes to place points bullets are shot from, particle origins, etc.   Anyone has heard of such a good sprite bank editor with these features, or are Spine/Spriter the only options at the moment? They're overkill for me but hey, I assume they can be used for simple stuff as well.   Thanks
  6. anothergol

    Best engine for me?

    Thanks.   Yeah SDL seems to be a great option as well. Heard about it a lot. Java.. I'd rather stay away from it (but maybe for wrong reasons).   I've watched some Godot tutorials, seems to be heavily event-based, but also with events happening on each game loop. But I haven't tried it yet. Building a tilemap looked painful, albeit powerful (with solidity zones for each tile).   Back then I had my own sprite editor, and I found it easier to put all of my sprites in banks, load & access each bank at runtime, so that I didn't have to hardcode sprite alignments / hot zones (hit boxes & other useful rectangles), & I didn't have to limit sprites to fixed rectangles. I hope such editors exist, especially with the added PITA to stack them efficiently on textures nowadays (I assume). That's a bit what attracted me to Godot, as each sprite seems to have its own zones - only for the tiles as well it seems way overkill. This said, I also like the idea of having the map made of freely-placed sprites, even though that then means there is no "map" anymore.   I don't even know how tilemap rendering is done nowadays - I understand the problem of stitching stretched tiles perfectly, I assume the only good option is a fixed-size render buffer that's later stretched-up, or tiles that bleed & overlap enough (but that requires the kind of illustrative artwork I can't do myself)
  7. anothergol

    Unity Best engine for me?

    Hello,   I've been programming for nearly 25 years now, and I'd like to get back to what I was doing 20 years ago: games.   But of course, a lot of things have changed, and I've myself changed. I don't have the patience I had back then, I'm not ready to asm-code every sprite blitter anymore, but well, it's what game engines & graphic cards are for today anyway.   So I wanna do 2D games, not that I don't like 3D, but I can still do pixel graphics, not 3D models. I come from Pascal, and while I think Pascal is the best language, I understand it's nearly dead by now - leaving the horrible Delphi & kinda bad FreePascal as the only compilers. So I'll have to learn a new (possibly scripting) language as well, and I guess it will always look more or less like C.   I've already tried Unity, but.. it didn't feel at all like how I was making games 20 years ago. To start with, I like to think in "game ticks", not "events". I kinda understand why an engine moves away from that, afterall you can't always force the graphic card to the refresh rate of your game's clock like you could under DOS. But.. I'd still prefer a game loop-based system, assuming there are still engines that work like this(?)   I've browsed game engines, picked some that felt like they were matching, so if anyone has any tip for me, thanks! I'd like to make a tile-based puzzler in the vein of Apogee's Paganitzu. Even though the graphics will be pixellated, I'd probably use the engine in full res, so that I can smoothly move sprites around, not snap them to pixels in a small, scaled up buffer. Since I'm moving away from the horrible Delphi, portablity is a big plus, thus I've picked those that appear to feature portability, at least to Android.   Is any of those the best for me? Or any other?
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!