Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1385091 Posts in 66316 Topics- by 58793 Members - Latest Member: Cookiesandfilm

November 26, 2020, 02:15:38 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsM.I.N.T (Mecha, Infantry, and Tactics)
Pages: 1 [2] 3 4 ... 26
Print
Author Topic: M.I.N.T (Mecha, Infantry, and Tactics)  (Read 61782 times)
t-recx
Level 0
**


View Profile
« Reply #20 on: January 18, 2013, 12:42:53 AM »

I want this inside my computer <3
Logged
Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #21 on: January 18, 2013, 06:04:36 AM »

Fun with Color Palettes

As we're using pixel art and an entire army shares a single palette, we were interested in if we could do palette swapping like many old games used to great effect.

Our main goal with this was to be able to swap army colors in multi-player without needing to use any extra video memory or disk space. It would of been quite wasteful if we had to load in something like 4 or even possibly 8 copies of all the units and their animations, just to have different army colors.

Sadly palette video modes and texture support seem to be all but about gone when it comes to modern video cards. Luckily we can re-create palette type functionality using pixel shaders. Which I've now completed and integrated support for into our framework, along with support for reading act files which photoshop uses to export palette/color table information.

So we now have basically video memory and disk space free army color schemes.

The other really cool part about this, is that we can also open up the ability for clans and even possibly just regular players to create their own color palettes and thus have custom army colors. Which other online players in a match will actually be able to see as well.

Its not quite as good as being able to paint your own table top miniatures, but its certainly quite a few steps in that direction.
« Last Edit: January 18, 2013, 06:13:16 AM by Zenroth » Logged

Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #22 on: January 18, 2013, 07:02:22 PM »

Working on the isometric engine. It looks like we will be going with a staggered isometric map layout instead of a diamond one.



The main advantages of this being that we can have nice fully contained map areas, unlike a diamond layout which results in nice map edges but also tons of empty space outside of the map that is normally visible.

Also in the case of the staggered layout we can hide the very edges of the map, and so you have none of the jaggies.

The next big questions is what do we need in the way of layers, and also the treacherous problem of depth sorting.

At the moment layer wise I think we will be using the following layers:

Base Terrain
Shadows
Obstacles/Buildings/Units

We might possibly end up with a fringe layer of sorts over the base terrain, and maybe and overhead layer, not sure.

On the topic of the evils of depth sorting an isometric scene, I'm currently going to try an take the easy way out of this problem and just split images so that they can confirm to 1x1 tiles. We will see how well that holds up in the long run.
 
Logged

SuperGT86
Level 0
**


Rural Australian dev studio.


View Profile WWW
« Reply #23 on: January 18, 2013, 08:19:09 PM »

Working on the isometric engine. It looks like we will be going with a staggered isometric map layout instead of a diamond one.



The main advantages of this being that we can have nice fully contained map areas, unlike a diamond layout which results in nice map edges but also tons of empty space outside of the map that is normally visible.

Also in the case of the staggered layout we can hide the very edges of the map, and so you have none of the jaggies.

The next big questions is what do we need in the way of layers, and also the treacherous problem of depth sorting.

At the moment layer wise I think we will be using the following layers:

Base Terrain
Shadows
Obstacles/Buildings/Units

We might possibly end up with a fringe layer of sorts over the base terrain, and maybe and overhead layer, not sure.

On the topic of the evils of depth sorting an isometric scene, I'm currently going to try an take the easy way out of this problem and just split images so that they can confirm to 1x1 tiles. We will see how well that holds up in the long run.
 

Looks good, what about elevation? Ie on top of a building or mountain, it will obviously complicate things more but add a bit to the tactics.
Logged

Kris with a K
Level 1
*


It's a good day to die.


View Profile
« Reply #24 on: January 19, 2013, 12:29:35 AM »

I'm not a huge fan of this style of mech, but that guy with the arms stomping about has a ton of swag. Sweet building detail, too.
Logged

Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #25 on: January 19, 2013, 02:32:13 AM »

Looks good, what about elevation? Ie on top of a building or mountain, it will obviously complicate things more but add a bit to the tactics.
Its a good question, I'm not sure what the plan is for elevation at the moment. We have to choose our features carefully, just to try an manage project scope some.

The game is already quite ambitious between not only the single player side, but also all of the work that will go into creating a simple and extremely polished map editor. Then there is the huge task of online multi-player and associated services like accounts, lobbies, ladders, map sharing, and so forth.

I think we will mostly be focusing on in-city combat across different types of setting, e.g. military bases, urban, industrial, etc.

Logged

DustyDrake
Level 10
*****



View Profile
« Reply #26 on: January 19, 2013, 02:42:29 AM »

Gotta say, love the art, hate the name, I hope it's temporary.
Logged

Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #27 on: January 19, 2013, 04:20:27 AM »

Well finished up the basic map rendering and camera system.

I can now scroll around an iso map with the jagged edges hidden properly.

Going to need to start thinking about map file formats and start in on a map editor.

I'm still divided between making the editor be built into the game or be a separate program. The biggest problem by far is the desire for it to be cross platform, which means using some GUI library like QT or just doing all my own GUI controls in OpenGL. Neither is particularly appetizing.

Maybe I should just consider java? Nah.
Logged

Impmaster
Level 10
*****


Scary, isn't it?


View Profile WWW
« Reply #28 on: January 19, 2013, 04:41:08 AM »

ART.  Crazy
Logged

Do I need a signature? Wait, now that I have a Twitter I do: https://twitter.com/theimpmaster
Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #29 on: January 20, 2013, 11:00:02 AM »

Started in on mouse picking support yesterday, turned out to be much more difficult than I imagined, but it was completed. So for those that are interested here is what happened.

-----------------------------------------------------------

I at first attempted to find and use various mathematic solutions to given a mouse point find the matching map cell it was over. There is actually a pretty simple formula for this in diamond maps, but it so doesn't work in staggered maps. Being terrible with math certainly didn't help my cause here either.

So I moved onto a solution from ancient times that should of worked perfectly fine. Which is to use a mouse map image. Basically you break your world space into a bunch of these rectangular images, then find where your mouse coordinate lands in the mouse map image. The mouse map image itself is broken into 5 colored sections, so depending on the section your mouse coordinate lands you need to move over a tile in that direction.

I spent hours battling with this. Maybe its because M.I.N.T's current tile work isn't a nice rectangle. Most of these games use something like 64x64 image dimensions with a base tile of like 64x32. I was using tiles that are 100x150 with a base height of 50.  At any rate I sort of got it almost working a few times, but the accuracy was less than ideal. I also realized that the mouse map while working fine for a flat map, doesn't really handle tiles and objects with height very well. For instance if I have a tile that is high and obscures 2-3 tiles behind it, and I click on the high tile the mouse map is doing to give me the map cell behind it.

So in the end I switched gears and went with a rendering based approach. Basically every object in the game gets assigned a unique id, and this id maps to a RGB color and back nicely. I then do a render of the scene to an offscreen frame buffer, but I draw everything as solid colors instead of using textures. The solid color matches the objects id. I then read back the pixels from the rendered scene and drop it into a buffer. Now it becomes super easy to just grab the pixel color the mouse is over from our buffer, convert it to an id and then lookup what the mouse is over based on the id.

This has some really nice benefits as its 100% pixel perfect picking and also handles objects and tiles with height perfectly. (At least assuming you want to know what was clicked, and not what was behind something.) The big downside is reading the pixel data back from the frame buffer comes with a pretty big performance hit. This is combined with needing to do two renderings of the scene.

Thankfully though we really don't need 30 or 60 snapshots of the screen a second to handle mouse picking, snap shots can be done at a much lower frequency and still be accurate. Likewise scene complexity can be reduced in many cases if needed a well for the colored version.

Performance wise I can currently still pull in around 120 FPS with a simple scene on a laptop with a Intel HD GPU, so I'm thinking it will likely be fine performance wise. (I imagine the game likely will run at 30FPS or so in the end.)

-----------------------------------------------------------

I'm otherwise still looking at what to do map editor wise. QT seems pretty huge and the code I've looked at with it so far is less than appealing to me. While at the same time neither is making a bunch of gui objects in pure OpenGL code either.

Of course another consideration is if I was to later want to port M.I.N.T to a tablet or something the game and the editor would need to be combined into a single app, and I'm doubtful QT or another windowing framework is going to port to mobile/tablets all that well.
Logged

rivon
Level 10
*****



View Profile
« Reply #30 on: January 20, 2013, 11:08:56 AM »

Take a look at these libraries:
CEGUI
libRocket
GiGi
BeGUI
libnui

They allow you to easily make OpenGL GUI.
Logged
Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #31 on: January 20, 2013, 11:14:40 AM »

Thanks rivon, I've seen some of these before, but have been avoiding them for some reason. I'll take a look though, starts to seem it might indeed make the most sense.
Logged

Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #32 on: January 20, 2013, 12:59:20 PM »

Took a look at the above OpenGL based libraries, going to look further into CEGUI. The rest seem to be under LGPL licenses or none specified in the case of libnui. I prefer to stay mostly in the realm of MIT/Zlib licenses to allow static linking if desired, and just to not have to worry about license infection in general.

I expect I'll have to mess with custom file and resource handling with any of these solutions though, given my normal use of compressed zip style resource archives.
Logged

rivon
Level 10
*****



View Profile
« Reply #33 on: January 20, 2013, 01:46:48 PM »

libRocket is under MIT license. And IMO CEGUI and libRocket are the two best ones, so yeah, pick whichever you like more - custom XML format or HTML+CSS (kind of).
Logged
Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #34 on: January 20, 2013, 01:50:40 PM »

libRocket is under MIT license. And IMO CEGUI and libRocket are the two best ones, so yeah, pick whichever you like more - custom XML format or HTML+CSS (kind of).
Oh yeah your right about libRocket, to be fair as soon as I saw it mention html and css I quickly jumped to the next one in the list. Smiley Slugging through the CEGUI custom xml docs currently.. all of it makes me miss my .net winforms a whole lot.
Logged

Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #35 on: January 20, 2013, 06:37:43 PM »

Well CEGUI is not looking good so far. Four hours of slogging through build issues, and then trying to implement its default OpenGL renderer.

Results? If I try an draw a basic window over my existing OpenGL work I get nothing. If I oddly disable my own OpenGL rendering, than CEGUI code crashes trying to send array info to OpenGL..

Not sure its worth all this effort, and its also seemingly quite heavy. Will have to decide what to do later, I'm burnt out on GUI pains for the day.
Logged

electrolyte
Level 3
***



View Profile
« Reply #36 on: January 21, 2013, 03:30:05 AM »

Quote
So in the end I switched gears and went with a rendering based approach. Basically every object in the game gets assigned a unique id, and this id maps to a RGB color and back nicely. I then do a render of the scene to an offscreen frame buffer, but I draw everything as solid colors instead of using textures. The solid color matches the objects id. I then read back the pixels from the rendered scene and drop it into a buffer. Now it becomes super easy to just grab the pixel color the mouse is over from our buffer, convert it to an id and then lookup what the mouse is over based on the id.

Gentleman

Having wrestled with hit areas in the past this is a great idea / solution, you could possibly use the same map to Raycast line of sight in future.
Logged

Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #37 on: January 21, 2013, 03:39:51 AM »

Gentleman

Having wrestled with hit areas in the past this is a great idea / solution, you could possibly use the same map to Raycast line of sight in future.

Now that is a brilliant additional application of this map, that I hadn't even thought about yet, but I see the potential already. Thanks Smiley
Logged

toipot
Level 0
**


View Profile
« Reply #38 on: January 21, 2013, 05:46:05 AM »

You could give gwen a try, it's a pretty lightweight GUI setup. I was going to give it a try, as it looked to me like one of the cleaner libraries available, but I decided to try and roll my own as a learning exercise (although I'm beginning to regret that  Facepalm ).

Are you using straight openGL or SFML/SDL?
Logged
Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #39 on: January 21, 2013, 06:31:36 AM »

You could give gwen a try, it's a pretty lightweight GUI setup. I was going to give it a try, as it looked to me like one of the cleaner libraries available, but I decided to try and roll my own as a learning exercise (although I'm beginning to regret that  Facepalm ).
Well I finally got CEGUI to work, ends up while it does its own matrixes and so forth, it doesn't handle all of the OpenGL state. My code was leaving a shader set and this was breaking CEGUI.  Still not sure I like how heavy it is, though I can certainly see advantages to the huge script driven approach, but its just a lot to absorb.

GWEN looks deceptively simple, I may check it out more.

Quote
Are you using straight openGL or SFML/SDL?

I'm using my own cross platform framework, that makes use of SFML for PC/Mac/Linux to do initial window setup, handle input, and for sound though thats likely to change sometime in the future. Quite tired of OpenAL and even the soft version of it.

All the rendering, texture loading, shader support and so forth is custom code.
Logged

Pages: 1 [2] 3 4 ... 26
Print
Jump to:  

Theme orange-lt created by panic