Tiles & Sprites
Moderator: Moderators
Oh I see, for some reason it doesn't in my browser.
I assume the RenderTile will mostly be used programatically and not really looked at that much in IDE, but in case something needs to be checked quickly maybe it'd be handier to show the whole tileset in the Preview area instead of showing only the current tile (identical to how it's done in the proposed Tileset component), and have the tile with the current index marked somehow?
Just so to offer the eye a bit of context in case the names of tilesets are kept short ("Cave3" and "Cave4" etc), or in cases where the tileset has a few similar tiles in a row with slight variations it'll be easier to confirm whether the right tile is being referenced etc etc..
This'd be impractical if somebody uses a gigantic tileset and/or a small monitor, but then they'd have te same problem when using the Tileset component anyway.
I assume the RenderTile will mostly be used programatically and not really looked at that much in IDE, but in case something needs to be checked quickly maybe it'd be handier to show the whole tileset in the Preview area instead of showing only the current tile (identical to how it's done in the proposed Tileset component), and have the tile with the current index marked somehow?
Just so to offer the eye a bit of context in case the names of tilesets are kept short ("Cave3" and "Cave4" etc), or in cases where the tileset has a few similar tiles in a row with slight variations it'll be easier to confirm whether the right tile is being referenced etc etc..
This'd be impractical if somebody uses a gigantic tileset and/or a small monitor, but then they'd have te same problem when using the Tileset component anyway.
My comments:
I didn't realize until now that the specification is interactive . Kjell, you spend far too much time on html/javascript coding
My first thought was also that RenderSprite and RenderTile have lots in common and could be combined into one. But perhaps it is more intuitive with separate components for tiles.
You mention that sprites and tiles should be rendered in pixel coordinates. Is this because it is meant to be used with a ortho (2d) camera so there can be a 1:1 pixel mapping between original bitmaps and render? And also so that collision tests can be made on integer coordinates? I guess we will need to have a good tile-game example that can be included with ZGE as a template.
Compatibility with a popular existing sprite/tile/font editor would be desirable but I don't have time to try them out and evaluate them. So hopefully this can be made later anyway and that the design we choose will be compatible with their data formats.
Spritesheet/font/tile editors: This is something that can be a hurdle because there are no built-in Delphi components for this so I know it will take me long to implement it. But since you already made editor demo projects (downloadable in the spec), perhaps we could make the editors in ZGE itself? Like we discussed earlier with a built-in sfxr clone. For instance, when a font is selected in ZGE it will find and load a "editors\fonteditor.zgeproj" project (or whatever we chose to name it). This project is run into the preview page and data between the users current project and the editor project will be transferred by ZGE (for instance, font character sizes can be written into an Array in the editor script, then ZGE copy from that array and store it into the users project). Probably some things need to be solved for that to work but the general idea that ZGE editor can be extended with ZGE scripts I think is a good one, because that allows you to contribute with ZGE functionality without having to code in Delphi.
I didn't realize until now that the specification is interactive . Kjell, you spend far too much time on html/javascript coding
My first thought was also that RenderSprite and RenderTile have lots in common and could be combined into one. But perhaps it is more intuitive with separate components for tiles.
You mention that sprites and tiles should be rendered in pixel coordinates. Is this because it is meant to be used with a ortho (2d) camera so there can be a 1:1 pixel mapping between original bitmaps and render? And also so that collision tests can be made on integer coordinates? I guess we will need to have a good tile-game example that can be included with ZGE as a template.
Compatibility with a popular existing sprite/tile/font editor would be desirable but I don't have time to try them out and evaluate them. So hopefully this can be made later anyway and that the design we choose will be compatible with their data formats.
Spritesheet/font/tile editors: This is something that can be a hurdle because there are no built-in Delphi components for this so I know it will take me long to implement it. But since you already made editor demo projects (downloadable in the spec), perhaps we could make the editors in ZGE itself? Like we discussed earlier with a built-in sfxr clone. For instance, when a font is selected in ZGE it will find and load a "editors\fonteditor.zgeproj" project (or whatever we chose to name it). This project is run into the preview page and data between the users current project and the editor project will be transferred by ZGE (for instance, font character sizes can be written into an Array in the editor script, then ZGE copy from that array and store it into the users project). Probably some things need to be solved for that to work but the general idea that ZGE editor can be extended with ZGE scripts I think is a good one, because that allows you to contribute with ZGE functionality without having to code in Delphi.
Hi rrTea,
However, i do see your point. Thing is, you've misread something on the Tileset page. It says Editor ( even though you can't edit anything ) instead of Preview ( a tileset cannot be previewed by itself ). But this principle could be applied / extended to RenderTile as well, so that you can check & select a tile using the editor. Here's a ( quick & terrible ) mockup ..
K
Ah, sorry .. i only tested it in ChromerrTea wrote:Oh I see, for some reason it doesn't in my browser.
Hmm, i disagree. The preview should only display what a component renders. I think it's important to keep this consistent.rrTea wrote:I assume the RenderTile will mostly be used programatically and not really looked at that much in IDE, but in case something needs to be checked quickly maybe it'd be handier to show the whole tileset in the Preview area instead of showing only the current tile (identical to how it's done in the proposed Tileset component), and have the tile with the current index marked somehow?
However, i do see your point. Thing is, you've misread something on the Tileset page. It says Editor ( even though you can't edit anything ) instead of Preview ( a tileset cannot be previewed by itself ). But this principle could be applied / extended to RenderTile as well, so that you can check & select a tile using the editor. Here's a ( quick & terrible ) mockup ..
K
Hej Ville,
Might be convenient to have a separate OpenGL context in the first place?
K
Maybe i should have mentioned that yesVilleK wrote:I didn't realize until now that the specification is interactive
I just think this is most intuitive. Several users have had quite some difficulty wrapping their head around the arbitrary sizes used by the RenderText component.VilleK wrote:You mention that sprites and tiles should be rendered in pixel coordinates. Is this because it is meant to be used with a ortho (2d) camera so there can be a 1:1 pixel mapping between original bitmaps and render?
Yea, desirable .. but definitely not required. Besides, it's usually pretty trivial to put together a quick importer using the File component.VilleK wrote:Compatibility with a popular existing sprite/tile/font editor would be desirable but I don't have time to try them out and evaluate them.
Yes please. If there was a way to "script" editors for components ( or even entire components themselves ) it would blow the lid offVilleK wrote:Spritesheet/font/tile editors: This is something that can be a hurdle because there are no built-in Delphi components for this so I know it will take me long to implement it. But since you already made editor demo projects (downloadable in the spec), perhaps we could make the editors in ZGE itself?
Sounds great. Personally i'd put editors in panel 4 though ..VilleK wrote:Like we discussed earlier with a built-in sfxr clone. For instance, when a font is selected in ZGE it will find and load a "editors\fonteditor.zgeproj" project (or whatever we chose to name it). This project is run into the preview page and data between the users current project and the editor project will be transferred by ZGE
Might be convenient to have a separate OpenGL context in the first place?
Yea, this would be huge ( it certainly has done wonders for Unity ).VilleK wrote:Probably some things need to be solved for that to work but the general idea that ZGE editor can be extended with ZGE scripts I think is a good one, because that allows you to contribute with ZGE functionality without having to code in Delphi.
K
Erm I think you misread my post, I was not talking about Tileset component at all, the RenderTile (which I was talking about) has a Preview as I wrote Anyway, the mockup does more or less what I had in mind (it shows the tile with the current index when using the RenderTile). Maybe only showing the lower part would be enough, just a thought.Kjell wrote:However, i do see your point. Thing is, you've misread something on the Tileset page. It says Editor ( even though you can't edit anything ) instead of Preview ( a tileset cannot be previewed by itself ). But this principle could be applied / extended to RenderTile as well, so that you can check & select a tile using the editor. Here's a ( quick & terrible ) mockup ..
Hi rrTea,
K
No i did not misread your post ..rrTea wrote:Erm I think you misread my post, I was not talking about Tileset component at all.
rrTea wrote:identical to how it's done in the proposed Tileset component
Again, i think it's important to keep things consistent and show what a component does / renders in the preview window. But you don't have to agree of course.rrTea wrote:Anyway, the mockup does more or less what I had in mind (it shows the tile with the current index when using the RenderTile). Maybe only showing the lower part would be enough, just a thought.
K
...which was mentioned as an example of how it's shown on the screen, not in terms of functionality (at least that's how it's meant ) It doesn't matter really...Kjell wrote:Hi rrTea,
No i did not misread your post ..rrTea wrote:Erm I think you misread my post, I was not talking about Tileset component at all.
rrTea wrote:identical to how it's done in the proposed Tileset component
Hi everybody,
The latest Beta now includes a SpriteSheet component and accompanying custom editor, and a updated RenderSprite component. Here's a quick explanation of the editor.
I'll be adding more features in the coming weeks .. including
- Automatically generate sprite definitions by analyzing the used Bitmap.
- Auto-fit ( grow / shrink ) a sprite by analyzing the used Bitmap.
- Selection of multiple sprites at the same time.
In case anybody has any comments, questions or suggestions .. let me know
K
The latest Beta now includes a SpriteSheet component and accompanying custom editor, and a updated RenderSprite component. Here's a quick explanation of the editor.
I'll be adding more features in the coming weeks .. including
- Automatically generate sprite definitions by analyzing the used Bitmap.
- Auto-fit ( grow / shrink ) a sprite by analyzing the used Bitmap.
- Selection of multiple sprites at the same time.
In case anybody has any comments, questions or suggestions .. let me know
K
Looks cool. What format(s) would you like to support for SpriteData?
Idea: if sprites are put to a grid then specification of sprite width and height (and border?) would also help; similarly to font. Or rather TileSet component (which is not available yet) should be used instead?
Remark 1: when creating a new SpriteSheet, it should have a default name; as other components.
Remark 2: It seems that RenderSprite produces too large image.
Remark 3: I have problems with redrawing the sprite sheet editor after some other ZGE dialogs or menus appear on top of it; see the screenshot.
Idea: if sprites are put to a grid then specification of sprite width and height (and border?) would also help; similarly to font. Or rather TileSet component (which is not available yet) should be used instead?
Remark 1: when creating a new SpriteSheet, it should have a default name; as other components.
Remark 2: It seems that RenderSprite produces too large image.
Remark 3: I have problems with redrawing the sprite sheet editor after some other ZGE dialogs or menus appear on top of it; see the screenshot.
- Attachments
-
- screenshot of incorrect redrawing
- scr.jpg (70.44 KiB) Viewed 14587 times
Hi Rado1,
2. Currently sprites are rendered at their native size. So a sprite of 16x8 pixels ends up being 16x8 units .. which is easiest to work with when setting up a pixel-perfect camera. But perhaps it would be useful to have a UnitSize property on RenderSprite ( so that when you use UnitSize = 8 on a 16x8 sprite it ends up being 2x1 units in size ).
3. Yikes
K
You want to use a TileSet for those kind of situations yes. A SpriteSheet would be a waste ( of data ).Rado1 wrote:Idea: if sprites are put to a grid then specification of sprite width and height (and border?) would also help; similarly to font. Or rather TileSet component (which is not available yet) should be used instead?
1. Agreed.Rado1 wrote:Remark 1: when creating a new SpriteSheet, it should have a default name; as other components.
Remark 2: It seems that RenderSprite produces too large image.
Remark 3: I have problems with redrawing the sprite sheet editor after some other ZGE dialogs or menus appear on top of it; see the screenshot.
2. Currently sprites are rendered at their native size. So a sprite of 16x8 pixels ends up being 16x8 units .. which is easiest to work with when setting up a pixel-perfect camera. But perhaps it would be useful to have a UnitSize property on RenderSprite ( so that when you use UnitSize = 8 on a 16x8 sprite it ends up being 2x1 units in size ).
3. Yikes
K
Kjell has done some amazing work here .
I agree it would be nice with a fast way to generate sprite regions so an auto analyze feature would be great. Kjell, if this is difficult to do I could make a button for it and implement it on the Delphi side.
We need a demo project that use the new features. Anyone know of some sprite data that can be used freely?
And should we continue with Tiles now?
I agree it would be nice with a fast way to generate sprite regions so an auto analyze feature would be great. Kjell, if this is difficult to do I could make a button for it and implement it on the Delphi side.
We need a demo project that use the new features. Anyone know of some sprite data that can be used freely?
And should we continue with Tiles now?
Hej Ville,
K
It's already working, i just need to add some fail-safe stuff for the "basket cases".VilleK wrote:I agree it would be nice with a fast way to generate sprite regions so an auto analyze feature would be great. Kjell, if this is difficult to do I could make a button for it and implement it on the Delphi side.
I'm on it! And i think for demo purposes it's warranted to "borrow" some sprites. In fact, it helps .. your mind fills in the blanks when you see something familiar.VilleK wrote:We need a demo project that use the new features. Anyone know of some sprite data that can be used freely?
You've got my vote At least it will take far less time to put together.VilleK wrote:And should we continue with Tiles now?
K