GameDev General #2
I was google searching some information on information regarding information about intermediate 3D model formats, and I came across this:
http://www.cplusplus.com/forum/lounge/113417/
It's a bit more than a year old, but I think it's a pretty interesting. It was going for ~7 pages before it died.
So, does anyone have any questions/want to discuss anything about game development?
http://www.cplusplus.com/forum/lounge/113417/
It's a bit more than a year old, but I think it's a pretty interesting. It was going for ~7 pages before it died.
| chrisname wrote: |
|---|
| Since a lot of us are into game development, I decided to make this thread a general discussion and questions topic about game development. |
So, does anyone have any questions/want to discuss anything about game development?
How do you handle text alignment and formatting, like in fancy game chat screens? It seems like a real pain with any of the APIs I've seen.
Yeah, text management is a real pain... in fact, I'm rewriting a system in my engine to properly handle it. I previously just loaded in a mono-spaced bitmap font with pretty much zero formatting capability.
I don't actually use any rendering libraries such as SFML or SDL, but I directly use Direct3D11 and OpenGL 3.3/4.4, so if SFML or SDL have a better third party API then I don't know. I do know that if you're using SDL you can use SDL_TTF. If you're using D3D, DirectXTK has a utility class for that sort of thing (best one I've seen IMHO). Sadly DirectXTK doesn't work with OpenGL, so I'll have to roll my own :(
This seems like a good start, but sadly it uses the FFP. It's pretty easy to convert to something modern, even if you're not using OpenGL:
http://nehe.gamedev.net/tutorial/freetype_fonts_in_opengl/24001/
And you could also look at DirectXTK's source code as well.
Once I finish mine, if I remember I'll try to open source it.
I don't actually use any rendering libraries such as SFML or SDL, but I directly use Direct3D11 and OpenGL 3.3/4.4, so if SFML or SDL have a better third party API then I don't know. I do know that if you're using SDL you can use SDL_TTF. If you're using D3D, DirectXTK has a utility class for that sort of thing (best one I've seen IMHO). Sadly DirectXTK doesn't work with OpenGL, so I'll have to roll my own :(
This seems like a good start, but sadly it uses the FFP. It's pretty easy to convert to something modern, even if you're not using OpenGL:
http://nehe.gamedev.net/tutorial/freetype_fonts_in_opengl/24001/
And you could also look at DirectXTK's source code as well.
Once I finish mine, if I remember I'll try to open source it.
Last edited on
As far as learning how to properly control text to align and fit with whatever is you need, I'd look at the methods used by a library like SFGUI.
Anyone care to explain multi-level tile maps to me? I'm curious how walls and roofs and multi-cell tiles are handled. What is an ideal way to represent large objects, like a castle or cliff face?
They're actually extremely simple.
Do you want to know how to draw them or how to represent them within your engine?
Representing them is straightforward. Just create another tile array with the same dimensions as the lower tile map, and store the values for the roof tiles there. Make sure to reserve a tile ID for air tiles, though.
The same way you store anything else. Each coordinate has it's own tile (or in this case, several tiles depending on the layer).
Do you want to know how to draw them or how to represent them within your engine?
Representing them is straightforward. Just create another tile array with the same dimensions as the lower tile map, and store the values for the roof tiles there. Make sure to reserve a tile ID for air tiles, though.
| What is an ideal way to represent large objects, like a castle or cliff face? |
ahcfan:
One way multi-level tile maps are done is just rendering another tilemap on top of the existing one, I have one game where each map has at least 2 tilemaps. but what exactly do you mean by your multi-cell tiles question? I'm not sure what you're asking here. As far as tall objects, you just make them longer in your tile map. Like look at final fantasy 6 that is a great representation of tall objects in a tilemap.
One way multi-level tile maps are done is just rendering another tilemap on top of the existing one, I have one game where each map has at least 2 tilemaps. but what exactly do you mean by your multi-cell tiles question? I'm not sure what you're asking here. As far as tall objects, you just make them longer in your tile map. Like look at final fantasy 6 that is a great representation of tall objects in a tilemap.
Last edited on
| Avilius wrote: |
|---|
| Representing them is straightforward. Just create another tile array with the same dimensions as the lower tile map, and store the values for the roof tiles there. Make sure to reserve a tile ID for air tiles, though. |
What is this about air tiles? Is it different than no tile?
| twiggystardust wrote: |
|---|
| One way multi-level tile maps are done is just rendering another tilemap on top of the existing one, I have one game where each map has at least 2 tilemaps. but what exactly do you mean by your multi-cell tiles question? |
What I mean is tiles that occupy multiple map cells. Like a tree for example.
Also maybe I should mention I'm talking about iso/hex maps, not top down.
Last edited on
If I'm getting what Avilius is saying yes, you do need a blank/air/no tile. just a blank spot on your tile sheet, but you do want to load it into your program. To make the bigger tiles, just make it two/three tiles what ever you need. I have a house on mine which takes up a 5 x 3 area of tiles. When you load it into your program, you just make that tile bigger, like say your regular tiles(grass, dirt, ect.) are 32 x 32, and your house tile is 5 x 3 tiles then the area of that tile would be 160 x 96. When you make your tile ID map, your just account for the tile that takes up more than one like say your map is 10 x 10 tiles. and your house is still 5 x 3 tiles, if you put the house on the top left corner, you would only need 5 more rows of tiles and 7 more columns. I hope that's what you're trying to find out.
Last edited on
Tile sheets are kind of archaic, so much so that Minecraft actually switched from using a tile sheet to using separate files for each graphic. The only reason tile sheets were used before was as an optimization long ago for old hardware. I recommend not using tile sheets anymore.
LB: Really? this is news to me. It seems counter-intuitive to load a ton of pictures in rather than load one in and cut it up within the code. And wouldn't that slow things down?
"recommend not using tile sheets anymore"?
I would be amazed if keeping them in separate texture files is faster now.
Surely it is better to include all your tiles in 1 png than have the GPU do 300 texture swaps. Even modern tutorials for Unity etc suggest having a texture atlas whenever possible. Of course for a minor 2D game you wont notice the difference anyway, but for AAA games?
Not saying you are wrong, but this is the first I have heard of it.
I would be amazed if keeping them in separate texture files is faster now.
Surely it is better to include all your tiles in 1 png than have the GPU do 300 texture swaps. Even modern tutorials for Unity etc suggest having a texture atlas whenever possible. Of course for a minor 2D game you wont notice the difference anyway, but for AAA games?
Not saying you are wrong, but this is the first I have heard of it.
Last edited on
Minecraft did not switch to using separate files because tile sheets are archaic. They did it to make life easier for texture pack creators, and to easily facilitate mixed/larger resolution resource packs with more animated textures.
-Albatross
-Albatross
| that Minecraft actually switched from using a tile sheet to using separate files for each graphic |
I think that was only during the transitional period.
I'm not saying that the in-memory representations can't be optimized with tilesets, I'm saying that tileset image files are dated and there is a reason Minecraft stopped using them.
I'm not saying that the in-memory representations can't be optimized with tilesets, I'm saying that tileset image files are dated and there is a reason Minecraft stopped using them.
| LB wrote: |
|---|
| The only reason tile sheets were used before was as an optimization long ago for old hardware. I recommend not using tile sheets anymore. |
Still used as an optimization today for at least one engine.
http://en.wikipedia.org/wiki/MegaTexture
Air tiles are just normal tiles that are not drawn.
I agree with everything else you say, but directly drawing over a sprite after it's been rendered results in a lot of overdraw and it's a solution that doesn't really scale well unfortunately (which pretty much only matters if your game renderers a lot of sprites).
You can perform a quick test in the renderer that decides what is drawn and what is not. Be careful though, too many checks will hurt performance rather than help it.
Wut?
Pretty much no game that cares about performance does not utilize tile maps. Texture switching is slow on modern hardware. Texture atlases are extremely common amongst professional developers. Accessing individual files is much slower than accessing one large one even if we're not talking about rendering.
The only ones I've seen that don't use them are relatively tiny indie engines, and even that's uncommon.
As stated before, it was for easy access to graphic files. Again, disk IO is extremely slow and it's not uncommon for assets (not only textures, but models & other files) to be packed into large binary blobs for them to be efficiently streamed into the engine during runtime.
| twiggystardust wrote: |
|---|
| One way multi-level tile maps are done is just rendering another tilemap on top of the existing one, I have one game where each map has at least 2 tilemaps. |
I agree with everything else you say, but directly drawing over a sprite after it's been rendered results in a lot of overdraw and it's a solution that doesn't really scale well unfortunately (which pretty much only matters if your game renderers a lot of sprites).
You can perform a quick test in the renderer that decides what is drawn and what is not. Be careful though, too many checks will hurt performance rather than help it.
| LB wrote: |
|---|
| Tile sheets are kind of archaic, so much so that Minecraft actually switched from using a tile sheet to using separate files for each graphic. The only reason tile sheets were used before was as an optimization long ago for old hardware. I recommend not using tile sheets anymore. |
Pretty much no game that cares about performance does not utilize tile maps. Texture switching is slow on modern hardware. Texture atlases are extremely common amongst professional developers. Accessing individual files is much slower than accessing one large one even if we're not talking about rendering.
The only ones I've seen that don't use them are relatively tiny indie engines, and even that's uncommon.
| I'm saying that tileset image files are dated and there is a reason Minecraft stopped using them. |
Last edited on
I guess it depends on the type of game you're making. With a game like Minecraft, using a tile sheet was a huge issue for things like mod support. Switching to individual files not only made mod support better, it also allowed for resource packs to change the textures and animations without modding the game.
Topic archived. No new replies allowed.