next »

[Gregg Williams]

Sorry for the lack of updates, have been sick since Friday, currently reworking the isometric rendering to hopefully solve some clipping issues that happen with units bigger than a tile.

[SyDaemon]

This gives me fuzzy memories from Front Mission 1!

Absolutely in love with the art style.

[Gregg Williams]

This gives me fuzzy memories from Front Mission 1!

Absolutely in love with the art style.

Cheers :D

So solved 99% of the clipping issues/artifacts, and have accepted the other 1% as unsolvable without changing some bits of art, which would result in an overall less quality. (Stuff like the big mech's gun barrel being slightly buried into a building when up against it, etc)

A big thanks to Christian Knudsen for talking about his isometric rendering process where he vertically slices things as needed during movement. Which led me to my rarely used friend glscissor and some nasty hacks.

Heres some fun visualizations of my glscissor rects to explain it.

 

So in the first picture you have a unit at rest. The green rectangle is a combined view of several glscissor operations. Essentially to work around art issues where some units are bigger than a single tile (like the barrels on the mech extend into a 2nd tile) yet are single tile units. As such all units are actually treated as if they were 2 tiles long. (I did say hacks right?)

Now to actually render a unit, the current tile to be rendered is glscissored and the unit is told to draw itself. This would result in part of the barrel missing, etc. However, since units occupy 2 spots in the map, its told to draw itself again at the 2nd location once the renderer reaches that location, which this time results in just the sliver of barrel being drawn, and everything else masked away.

One of the main things to work out here was the width and offsets of the glscissor rects, as preventing overdraw was necessary due to translucent art like the shadows, and eventually other bits. It ends up though that there is a simple pattern to this, where the "real" locations is always full width, and any "fake" locations end up half width and potentially offset by half a tiles width based on unit facing direction. (Got to love ISO)

The second picture is a bit of another hack but was necessary. Basically anytime a unit is moving, we create a 3rd "fake" entry for it based on its facing direction. Otherwise as that mech moved from the back square, one tile forward the barrel would extend beyond the two tiles ,and get clipped slightly.

To be fair, pretty much all of these issues and of course the recent 10 year animation saga, come down to this heavy mech bugger ;p Ah well we love him anyways. The downside to this approach really is that units are rendered multiple times unnecessarily, although pretty much everything is rejected away early anyways thanks to the scissor rects. I'm not really worried about performance of this at the moment, but if I was, it would be easy to extend this system to only be used with certain units vs every unit.

Technically it would also be pretty easy to support real multi-tile units now I suppose via this system, but I don't believe we have any of those planned currently as I was pretty stern about trying to keep ISO issues in check. (*Waits for the 8 leg scorpion tanks, and multi-tile long heavy artillery platforms to start rolling in just to cause me extra grief.*)

[Christian Knudsen]

A big thanks to Christian Knudsen for talking about his isometric rendering process where he vertically slices things as needed during movement. Which led me to my rarely used friend glscissor and some nasty hacks.

Glad to be helpful! And if you end up adding multi-tile units, give me a holler and I can probably provide some tips again.

[Gregg Williams]

A big thanks to Christian Knudsen for talking about his isometric rendering process where he vertically slices things as needed during movement. Which led me to my rarely used friend glscissor and some nasty hacks.

Glad to be helpful! And if you end up adding multi-tile units, give me a holler and I can probably provide some tips again.

Cheers I may have to take you up on that if things like this guy continue to flow forth.

[Gregg Williams]

Oh yeah and there is this new little mockup

[SyDaemon]

If there were figurines for sale for these I'll buy them in a heart beat. 

[Gregg Williams]

If there were figurines for sale for these I'll buy them in a heart beat. 

That's totally going to happen at some point.

[Impmaster]

I still can't wait for this to stop simply looking pretty and to change into something we can play.

[Gregg Williams]

I still can't wait for this to stop simply looking pretty and to change into something we can play.

I feel the same way, that's gonna take awhile though.

[Gregg Williams]

In other news, fixed movement again, after breaking it horribly with that big mech animation. Also added in idle animation support.

Resuming work on huds, and cursors, to enable more game play and pew pew

Also started work on a little static landing page for the game, seems like there needs to be one, especially when press starts to call the game in RTS :D

[Gregg Williams]

Worked in support for mouse based unit detection. (Overlapping bounds and closest sorting, etc)

Added in initial support for base unit stats such as movement rate, action points, health, and armor. Expanded Lua function definitions to support these, and updated movement system on client and server to use them.

Updated the server to have Lua functionality.

Worked on the hud a bit more, going to be dropping a crude version of that into the game soon, to move forward with more gameplay progress.

[NinthPower]

This is turning out to be really awesome!

[Gregg Williams]

Been working on Fire Arc support a bunch, as Kawe takes a look at making something decent out of my hud wireframes.

Thankfully initial support for fire arcs is now done, with only a bunch of headaches with rotating arbitrary sized 2D arrays, and translating them to the isometric map.

Anyways the following is super early, but its basically showing a fire arc that is defined as

1,1,1
1,1,1
1,1,1
0,1,0
0,2,0

The fire arc will happily rotate around based on facing direction of the unit, and they end up being easily defined in the weapon's Lua file.

[Gregg Williams]

Plugging away at todo items to reach initial combat status. Sadly though we want to support localization, so next few days of work will be coding up a solution for that. CSV's, string tables, replacement fun stuff. Joy :D

I may just end up porting FireTongue from Haxe, and making my C++ version of it publicly available. Seems like there is no light weight solutions to this in C/C++, its use gettext, boost, or icu, all of which are massive.

[ANtY]

Been working on Fire Arc support a bunch, as Kawe takes a look at making something decent out of my hud wireframes.

Thankfully initial support for fire arcs is now done, with only a bunch of headaches with rotating arbitrary sized 2D arrays, and translating them to the isometric map.

Anyways the following is super early, but its basically showing a fire arc that is defined as

1,1,1
1,1,1
1,1,1
0,1,0
0,2,0

The fire arc will happily rotate around based on facing direction of the unit, and they end up being easily defined in the weapon's Lua file.

good that u got those arcs working properly

[Gregg Williams]

Non-PA logo

Still playing with / procrastinating from doing this localization work, but I plan to squash it tomorrow, and move forward.

That and get a landing page / indiedb page setup for the game.

[Gregg Williams]

Basic string table/csv junk is working, needs a bit more work. UTF-8 code points are working (Thanks utfcpp), font system needs re-written to use code points.

[nikolail]

[Gregg Williams]

Haha thanks I'm working on it. Honestly the 18th I got phase one of a root canal done, and have been laying in bed a bit tripping on Vicodin and ibp since...