Sprites #13
Comments
|
I think Raylib has quite a bit of sprite support we could probably port with minimal effort. I designed a texture packer for frag and a texture format which we could easily port over to this engine. In regards to the spine implementation, yes it did go very well and I think we can also port it over here with some effort. I'll triage these shortly and get them in order that I think they can be addressed. I think this one is probably top in priority and then examples. |
|
AFAICT, Raylib supports spritefonts and rendering to textures; and that's it. When I meant sprite, I mean more complex lines like animation & sequences. That's what I made in Masala. |
|
Gotcha - I was under the impression raylib had more support than that. Sure we can borrow from your work on Masala then. Feel free to take this on and if you have any questions I can try to answer them. As far as formats go, we should pick something easily parsable and preferably parsable by existing solutions so we don't have to invent our own. For frag I used the https://nim-lang.org/docs/parsecfg.html module and my texture packer spit out textures in this format - https://github.com/fragworks/frag/blob/master/tools/texture_packer/tinydeflate/tilesheet.atlas Even if we have to write our own parser, that's fine, but I think using popular formats might be a better option - your thoughts? |
|
I designed that format so it could be edited with a text editor. It's not the most optimal or space saving, but I think it did work pretty well for me. As long as it's documented we should be fine for the short-term, but in the long term we should make some tools were people can do things such as select frames, order them into sequences, define origin points, pack them into one sheet, and save the file. |
|
I'm editing the original comment to use it as a TODO list. |
|
@zacharycarter I've got two questions that need answers for you:
|
Ideally the drawModel proc would take in as a parameter, and I think it should be the same for whatever other draw methods we have that need timing. We can build samples with example game loops.
|
|
Doing It's not synced with the current logic frame or render frame. Say if we call Since it also has to go through a whole call stack, (and fetch the location in memory), it can lead to slowdown as well. It would be better to call Also IIRC, This is starting to get out of the scope of the Sprite object, shall I make a new ticket for this? |
|
I agree we shouldn't use sdl.getTicks() probably the high performance counter sdl2 offers or your stopwatch package. I think sdl2's high performance counter will work for mobile too so that's something to consider. If anything I'd rather have a timer module which does what you're describing for us. I'll make a new issue for this and we can discuss further there. |
|
Mind if I reserve |
|
Go for it. Also feel free to put a PR in for stopwatch use, etc... |
|
Little bit of an update now. I got done with the basic I think |
|
Right now there's a default shader that gets loaded at startup. You can also load models with specific shaders, although it might make more sense to allow you to pass in a shader on a particular draw call. I'm going to be away this weekend, but when I get back let's review what you have so far (please make a PR) and we can figure out how best to integrate your changes. To answer your question - models are loaded in model.nim and then there are two functions in zgl that have to do with them - loadModel and drawModel. All the required shader setup etc is either handled by the setup of the default shader with the zgl module initializes, or is taken care of in the example file. |
|
Well, I do need to clarify that no rendering is happening at this moment. It's only loading and parsing. If you're still fine with merging that in for the moment I'll make the PR, but I'd really like to get something drawing on the screen first. I don't like saying "we have sprite, but we can't draw them at the moment." |
|
I added a new question: What should we consider the origin of the sprite to be? I'm not talking about the origin within the I know that traditionally in 2D games we used a Cartesian graph that was flipped along the X axis, with (0, 0) being the top left of the screen, and (0, 0) being origin of the sprite (which was also in the top left). But we're working in 3D, and that's where our sprites live. I'd like to propose that we should use a normal Cartesian graph, with (0, 0) being in the center of the screen. As for the sprite, the origin of the sprite should be the absolute center. This might get slightly tricky when we have to deal with an animated sprite who's frames are non all of the same dimension, but I think this is the best solution. What are your thoughts? EDIT: additional discussion here: #33 |
|
Actually, I think I'll send you a PR soon for what I have (minus some testing code). |
At this moment we are able to read and parse in a very minimal .zsprite file. So far we can do things like define frames, sequences, add looping modifiers, etc. Righut now there is a `Sprite` object, and a `ZSprite` object (which is a child of `Sprite). They are mainly ment to be dumb data containters that only are for managing the state of a sprite object (e.g. timing, which frame to show, etc). In the futur we plane to have sprites that are defined by the `Spline` format, so that's why I made the common `Sprite` base object. In case a game dev also wants to make their own custom sprite they can two sub-object it too. The rendering logic (and OpenGL state) is going to be put inside the `SpriteBatch` object. Right now it's only going to support ZSprites, but in the future will support SplineSprites. Since at the moment there are some other things that need to be decided on (such as sprite coordinate systems) and some other code implemented(e.g. a timing system, instead of using `sdl.getTicks()`), they are only rendering their spritesheets at the moment, as proof that we can load up a ZSprite and show something. The example `03` for sprites isn't also done yet either, so I decided not to include the code. I'm only reserving the name. Don't consider issue zacharycarter#13 done yet. This is only the first step.
|
PR for what I've got so far is right here: #32 |
At this moment we are able to read and parse in a very minimal .zsprite file. So far we can do things like define frames, sequences, add looping modifiers, etc. Righut now there is a `Sprite` object, and a `ZSprite` object (which is a child of `Sprite). They are mainly ment to be dumb data containters that only are for managing the state of a sprite object (e.g. timing, which frame to show, etc). In the futur we plane to have sprites that are defined by the `Spline` format, so that's why I made the common `Sprite` base object. In case a game dev also wants to make their own custom sprite they can two sub-object it too. The rendering logic (and OpenGL state) is going to be put inside the `SpriteBatch` object. Right now it's only going to support ZSprites, but in the future will support SplineSprites. Since at the moment there are some other things that need to be decided on (such as sprite coordinate systems) and some other code implemented(e.g. a timing system, instead of using `sdl.getTicks()`), they are only rendering their spritesheets at the moment, as proof that we can load up a ZSprite and show something. The example `03` for sprites isn't also done yet either, so I decided not to include the code. I'm only reserving the name. Don't consider issue zacharycarter#13 done yet. This is only the first step.
|
I also could use a proc in |
|
Also, sprite transparency seems to not be working. If you check the sheet for
|
|
Are you fine with me using this sprite as one for a more complex example? https://opengameart.org/content/platformer-animations I'd like to doodle my own animation (like I did with the Blau Geist), but I'd rather get some more core stuff done first. |
|
I'm cool with that |
|
Good. Later on I might replace it with an original animation. Something I do want to note, after I get done with this issue and #34, I'm going to duck out a little bit from zengine to finish up another project I've been juggling around for the past 3-4 months. I'll come back to focus more on zengine, but I've learned that I need to do one thing at a time. If I'm lucky I should only be gone for a month or less. I'll still probably log issues and ideas. If any issues arise from the sprite module I'll come and fix them. |
At this moment we are able to read and parse in a very minimal .zsprite file. So far we can do things like define frames, sequences, add looping modifiers, etc. Righut now there is a `Sprite` object, and a `ZSprite` object (which is a child of `Sprite). They are mainly ment to be dumb data containters that only are for managing the state of a sprite object (e.g. timing, which frame to show, etc). In the futur we plane to have sprites that are defined by the `Spline` format, so that's why I made the common `Sprite` base object. In case a game dev also wants to make their own custom sprite they can two sub-object it too. The rendering logic (and OpenGL state) is going to be put inside the `SpriteBatch` object. Right now it's only going to support ZSprites, but in the future will support SplineSprites. Since at the moment there are some other things that need to be decided on (such as sprite coordinate systems) and some other code implemented(e.g. a timing system, instead of using `sdl.getTicks()`), they are only rendering their spritesheets at the moment, as proof that we can load up a ZSprite and show something. The example `03` for sprites isn't also done yet either, so I decided not to include the code. I'm only reserving the name. Don't consider issue zacharycarter#13 done yet. This is only the first step.
This is now a TODO list for me. The original comment is quoted at the bottom.
TODO:
SpriteBatchobject for rendering. Give it some extra fun things like blending options and whatnotQuestions I've got:
The text was updated successfully, but these errors were encountered: