Say hello to my newest game! :D
(http://i.imgur.com/r4b0thA.png)
(http://i.imgur.com/xjGq8Bp.gif)
Currently not much done, but that comes with the time :)
It is written in C, as that goes the fastest, looking at the fact this will be a really large program..
I already have an idea about an AI, and hopefully when this program sees the finish line, that USB is somewhat documented, that I can add multiplayer.
To-Do list:[list=1]
- Make images of all the buildings/soldiers/villagers, and make them fit into my tiles (catch them from AoE II)
- Buildings 1/25
- Soldiers/villagers 0*8/40*8
[/color]
- Gameplay GUI
- Minimap
- Amount of max villagers/villagers
- Tiles
- Chat
- Extra options
[/color]
- Be able to create soldiers/villagers at the town center/barracks etc
- Check if enough resources, stand-by place
[/color]
- Move people to certain places
- Requires shortest path finding algorithm
[/color]
- Gathering resources
- Disappear resource if empty
- (Animated villagers)
[/color]
- Building/Fighting
- Check if enough resources/health
[/color]
- AI
- Write a website/.exe file to make an AI yourself
[/color]
- Multiplayer
- Only if USB is somewhat documented
[/color]
Btw:
(http://i.imgur.com/a6T0qf4.png) :P
if you ever get it working as good as the original AoE2, I swear I'll buy a CE jsut to play that game O.O
this is a massive project XD
looks good :)
Quote from: p2 on January 03, 2017, 10:03:15 PM
if you ever get it working as good as the original AoE2, I swear I'll buy a CE jsut to play that game O.O
Well, I definitely can't get it as good as the original one, just because of the hardware differences/screen size, but I would surely give it a try :w00t:
Looks awesome! Runs pretty good so far - hopefully it can remain as such with more stuff on screen.
The isometric look is great :).
PT_ how are you going to deal with selecting multiple units at once and that sort of thing
Quote from: kotu on January 03, 2017, 10:32:24 PM
PT_ how are you going to deal with selecting multiple units at once and that sort of thing
If you double click on a unit (don't know how), it catches all the units in a circle with radius X, and selects them all. One hard part would be moving all to the same point.
Quote from: PT_ on January 03, 2017, 10:33:55 PM
If you double click on a unit (don't know how), it catches all the units in a circle with radius X, and selects them all.
you could also use select all on screen, or select all units of same type
Quote from: PT_ on January 03, 2017, 10:33:55 PM
One hard part would be moving all to the same point.
that is where the pathfinding becomes very tricky . i'm not going to help 8)
ingame (AoE2) doubleclick is selecting all of same type while you use to drag a box around units to select multible at a location
:love:
I got some buildings ready:
(http://i.imgur.com/sJdw2rC.png) - Barracks
(http://i.imgur.com/j4XpVsS.png) - Farm
(http://i.imgur.com/XJORw8M.png) - House
(http://i.imgur.com/iHexh0H.png) - Lumbercamp
(http://i.imgur.com/52IFTrS.png) - Mill (yes, mill!)
(http://i.imgur.com/q8Nkgy6.png) - Miningcamp
(http://i.imgur.com/d5SIvAJ.png) - Towncenter
Woah those graphics and isometric tilemapper... nice job so far. Good luck getting this project done. :)
Only one issue tho: there is some white stuff around the towncenter
Looks very nice, although I don't own that calculator I'm looking forward to this ;)
Quote from: DJ Omnimaga on January 04, 2017, 07:34:07 PM
Only one issue tho: there is some white stuff around the towncenter
My guess is that the conversion from non-transparent white background to transparent had some issues, but this is probably quickly solved ;)
Quote from: DJ Omnimaga on January 04, 2017, 07:34:07 PM
Woah those graphics and isometric tilemapper... nice job so far. Good luck getting this project done. :)
Only one issue tho: there is some white stuff around the towncenter
Yes that was the image I downloaded from the internet. I've already removed all that separate pixels *.*
Btw, the compressed sprites are all together 42kB, and without compression 120kB :P
By the way, will there be a mini-map?
Quote from: DJ Omnimaga on January 04, 2017, 09:43:08 PM
By the way, will there be a mini-map?
Definitely! I'm going to add a gameplay GUI, if you press [MODE] you will get there, and from there, you can see the minimap, you can build houses, etc.
Btw, I've moved off from C, it's for me too hard to learn. Instead I will program this in ASM, but with the C libs included. I'm already at the stage I was in C.
Interesting that you moved from C to ASM due to ease of programming :).
Have you any updated animated screenshots?
Quote from: tr1p1ea on January 04, 2017, 10:12:52 PM
Interesting that you moved from C to ASM due to ease of programming :).
Have you any updated animated screenshots?
:P The one I posted is still the latest one, as I didn't add anything else, other than buildings
(http://i.imgur.com/gKSEgVb.gif)
there as an HD remake of Aoe2, only 1-2 weeks ago another extension was published (I made a post somewhere...)
but I suppose you use the basic low res tiles? :)
(of AoE2 not AoE1, right?)
Quote from: p2 on January 04, 2017, 10:16:02 PM
there as an HD remake of Aoe2, only 1-2 weeks ago another extension was published (I made a post somewhere...)
but I suppose you use the basic low res tiles? :)
(of AoE2 not AoE1, right?)
I'm making an AoE2 port, and since I don't have the HD version (yet), I'm making the old one.
Looking really promesing. I wonder if you'll be able to finish it (im not sure how big AoE2 is :P).
Progress so far:
- Rendering of all the buildings is ready, I only need to add one thing, and that is when the building is entirely offscreen, it would skip the decompression + displaying part, to save speed.
- Resources (Wood, food, gold, stone) + population/max population at the top of the screen.
(http://i.imgur.com/e94sdCR.gif)
The crash at the end only happened special for this screenshot.
Oh, and my lil' bro said the lumbercamp and the miningcamp are 2x2 tiles, so I need to change that.
meh
think a population max of around 50 would be better for the calc?
Well, speed is a real struggle, but I got it working ;)
(http://i.imgur.com/4uGIkZL.gif)
Sorry about the speed. This looks really great, though. You might have to use shortcuts such as storing buildings directly inside the map data so you only have 1 layer of stuff to draw.
@tr1p1ea once made an isometric tilemapper on the CSE once that had multiple layers, though, so maybe he could help you?
Or you could make the buildings smaller.
Im Not sure about that, how big would the speed improvment be in you resized all tiles to 50% size?? Generally speaking that should be a good idea as there would be only very fes buildings ob the screen Art once...
how about a building drop game where you have to drop buildings on large gangs of aoe priests??
Quote from: p2 on January 05, 2017, 08:31:45 PM
Im Not sure about that, how big would the speed improvment be in you resized all tiles to 50% size?? Generally speaking that should be a good idea as there would be only very fes buildings ob the screen Art once...
If my brain is working correctly right now, reducing the size of the tiles doesn't reduce the time it needs to fill a screen with x*y tiles. If I'm not wrong it probably only makes it worse :trollface: (except he has to load tiles OTF, but that's too MLG)... I'm just asking myself, depending on how this isometric thing is written, if you actually have to 'overdraw' the edges? I guess non-isometric would be faster, but also not as 1337...
Im sure things can be sped up with some optimising ... though those are some big sprites to be drawing :(.
This is in ASM, but using CE libs for the drawing functions?
You could just pull a super mario bros 2 and make a few sprites to a building
Quote from: p4nix on January 05, 2017, 08:37:52 PM
Quote from: p2 on January 05, 2017, 08:31:45 PM
Im Not sure about that, how big would the speed improvment be in you resized all tiles to 50% size?? Generally speaking that should be a good idea as there would be only very fes buildings ob the screen Art once...
If my brain is working correctly right now, reducing the size of the tiles doesn't reduce the time it needs to fill a screen with x*y tiles. If I'm not wrong it probably only makes it worse :trollface: (except he has to load tiles OTF, but that's too MLG)... I'm just asking myself, depending on how this isometric thing is written, if you actually have to 'overdraw' the edges? I guess non-isometric would be faster, but also not as 1337...
It depends of the calculator. On the CSE the speed is entirely dependent on how much of the screen is updated, so smaller tiles makes a considerable difference. On the CE and monochrome calculators, not as much, but it probably really depends of how the thing is drawn. If you have to draw an entire background tile by tile, then on top of that a bunch of buildings that fills most of the LCD a second time, then that's a serious speed drain compared to if the buildings are part of the map. However, by making buildings part of the map, you need to keep a copy of the original map with no building on it cached somewhere, so that when a structure is destroyed or salvaged, you can restore the original map state in that location.
Also, if you notice in Starcraft, while the maps are isometric, the building footprint is tiled. So another solution is to use fake isometry, meaning that graphics look like isometric, but each tile is still a 16x16 chunk. This makes it harder to store and manage sprite data and create maps, though.
I've been talking with PT_ about making custom spriteblit functions which only care about the pixels which actually need to be drawn (using unrolled ASM code) instead of having sprites with transparency. This way, rendering will probably be faster - also the tiles will have their own data format and thus are smaller in size. Downside is that it is a little bit more complex and that you need a conversion tool.
I believe Runer112 and Mateo are creating a new and faster way to display (clipped) transparent sprites, which will be 5-10 times faster, so maybe I will just stay with the normal C routine, which could maybe lead me to something like 20 FPS :w00t: In the meantime, I will still continue this project, and add more stuff, once his routine is complete, I will try to speed it all up :)
That's nice! But even if they do it, you still might want to unroll this since you always know where the transparent parts will be ;)
The last screenshot I posted was about 2 FPS (it took 20 million clock cycles), but I made some changes which speeds it up. First of all, I've decreased all buildings to 50%, to see more buildings at the screen. This lifts the FPS up to about 9. Next, I heard Runer112 and Mateo are writing a new TransparentSprite routine, which could lead to an FPS of maybe 20 or even more. But while that routine is not available yet, TheMachine02 decided to write a special routine for me, which displays only the isometric tile, not the transparent corners. The unclipped version was about 7 times faster than the clipped TransparentSprite routine, but he needs to add clipping to it, so I don't know how much faster it would be. My last point is that I'm now going to write a routine to display only a part of the tilemap. My current routine is just 2 For-loops, but that is bad, because with large maps 90% of the tiles will be entirely offscreen, so if my routine just stops with drawing if the tiles are offscreen, I could save a lot of time, which lifts the FPS again up! :crazy:
Quote from: PT_ on January 07, 2017, 03:53:13 PM
My current routine is just 2 For-loops, but that is bad, because with large maps 90% of the tiles will be entirely offscreen, so if my routine just stops with drawing if the tiles are offscreen, I could save a lot of time, which lifts the FPS again up! :crazy:
Remember that you do not even have to test if they are offscreen or not using the right method ;)
@PT_ If you want I can give you my pathfinding algorithm. (It would have to be ported to C of course :P)
Anyway, looks neat! Good luck!
This looks amazing! I was trying to make a game of similar mechanics, but I haven't finished. I may or may not end up making it, but if I don't, succeed where I couldn't!
Here is my pathfinding algorithm.
@PT_ Subroutine: AStar
CALL PushNode(OpenStack,StartingX,StartingY,0,0,0) // this sets the starting node and sets it's distance to the goal to 0. (that value doesn't matter it can really be anything since the x and y cords. determine if the goal has been found) I set its parent's x and y to 0 so when I am calculating the path at the end, I know that it is the starting node.
While ("tmpOpen" is not empty){
If (!PathFound){
CALL Calc1Node //this doesn't really need to be a subroutine but it makes it easier to read
}Else{
Return //Sucess! Each node points to the previous one in the path so all you need to do is return up the stack starting with the node on the goal
}
}
Return //Fail! no paths exist to the target!
Subroutine: Calc1Node
Find the node that is the closest to the target on the open stack and pop it off the stack. You should ignore the node if it is on an impassible tile or already exists - It is perfectly fine to only add a couple nodes. You will only add 8 nodes on the first tile as every other tile will be adjacent to the tile that called it.
Calculate the 8 nodes nearest to it and their distance from the target (I used sqrt(abs(Y-TargetX)
2+abs(Y-TargetY)
2)+ValueOfTile ValueOfTile is how much movement is needed to cross this tile - higher numbers are harder to cross!)
Push each of the nodes onto the open stack. Make sure to have them include their parent node's location! However if the node is on the goal tile, push it to the closed stack and set PathFound to true.
Push the node that was evaluated (the one that was popped off when this was called) onto the closed stack
Return
PushNode
/*
Node Structure
Toal: 6 bytes
1b: NodeX
1b: NodeY
2b: Distance to goal
1b: parentX
1b: parentY
*/
Pushes the node to either the open or closed stack. I inserted memory on the end of the appv to do the least amout of shifting. I also refound the pointers for both stacks in case they moved.
Return
PopNode
//pops a 6 byte node off the open stack. See node structure...
I used deleteMem once the data was retrieved.
I also refound the pointers for both stacks in case they moved.
Return
Define: "tmpOpen" //list of nodes left to be checked
Define: "tmpClosed" //list of nodes that have already been checked
Note: this returns the path form finish to start. You will want to make the goal pathfind to the unit!
That's all! @ me if you have questions!
Awesome speed increase PT_ :D
Quote from: p4nix on January 07, 2017, 03:57:16 PM
Quote from: PT_ on January 07, 2017, 03:53:13 PM
My current routine is just 2 For-loops, but that is bad, because with large maps 90% of the tiles will be entirely offscreen, so if my routine just stops with drawing if the tiles are offscreen, I could save a lot of time, which lifts the FPS again up! :crazy:
Remember that you do not even have to test if they are offscreen or not using the right method ;)
that's true, you can assume only correct map data si used, which means there are no structures//buildings off border or on the border. SO don't waste time on checking for them as they never exist ingame ;)
Good news: I found this thread: http://www.java-gaming.org/index.php?topic=24922.0 which explains pretty well how to draw only a part of the isometric tilemap, and hopefully it is enough to speed it up a lot :)
tl;dr :ninja:
but I really hope It wll help you speeding it up. Good luck PT_ :thumbsup:
Good luck PT_. Hopefully this alleviates your speed problems. :)
'Long' time no update, I was pretty busy with exams and stuff, but I picked it up again, now that I have some more free time, and decided to implement the algorithm I already mentioned before. But the problem is that that algorithm doesn't work fine, and I don't know how to quickly solve it :(
The algorithm is basically like this:
(http://i.imgur.com/dHiifRz.png)
with this code:
{...}
boolean nBump = false, mBump = false;
int n = 1, nStart = 1, nBuffer = 1;
int m = 1, mStart = 1, mBuffer = 1;
for (int i = iStart; i < iMax; i++) {
// Testing Purposes
// Sleep 1 second each i iteration and paint the screen
// TODO
// .......
for (int j = jStart - n; j < jStart + m; j++) {
// paint the column
colArray[ hWrap(i)][ vWrap(j)].paintAll(g);
}
// adjust m and n to keep us within the screen
// adjust n
if (!nBump) {
//we have not yet reached the lowest j point
// increment n to go even lower next iteration
n++;
// Check if we have reached the lowest j point
if ((jStart - n) == jMin) {
nBump = true;
//System.out.println("Bump N");
}
} else {
// we have reached the deepest j and are now going back
// start decreasing after the buffer is gone
if (nBuffer > 0) {
nBuffer--;
} else {
// The buffer is gone, start decreasing n each iteration
n--;
// check that n never exceeds its starting point
if (n < nStart) {
n = nStart;
}
}
}
// adjust m
if (!mBump) {
// we have not yet reached the HIGHEST j point
// increasee m to go even higher next iteration
m++;
// Check if we have reached the highest j point
if ((jStart + m) == jMax) {
mBump = true;
//System.out.println("Bump M");
}
} else {
// we have reached the maximum j point
// and are now moving back.
// start decreasing m after the buffer is gone
if (mBuffer > 0) {
mBuffer--;
} else {
// The Buffer is gone
// decrease m each iteration
m--;
// check that m never exceeds its starting point
if (m < mStart) {
m = mStart;
}
}
}
}
}
}
But if I do almost the same steps in my own tilemap, I get this:
(http://i.imgur.com/j4mSSim.png)
(I assume now that the blue rectangle is the visible screen)
The orange line is how it should be, but the yellow line is the outcome of the algorithm.. Anybode that can help me out? :)
EDIT: 1 minute after posting, I got the solution... I need to change nBuffer to be not 1, but the amount of tiles that can fit horizontally in the screen... Sorry for disturbing you ;) :ninja:
Sounds neat! Can you rotate the camera angle?
What are you working on next?
Great to see progress. I am curious about how much faster the new algorithm is :3=
It's not going super bad, as I expected. The blue rectangle was my test 'screen', and I need to change checking the Y coordinate..
(http://i.imgur.com/oNimBjG.png)
Do you mean on a real calc you only displayed whatever was in the rectangle?
The poblem he's talking about is which parts of the map to load // render.
especiallly on a calculator the time necesary for each step (loading, inputs, renddering, whatever) is extremely crytical.
So he has to optimize it to the absolute maximum :ninja:
And yess I assume the blue rectangle is ment as a "screen" to test how far the program already distinguishs between fields to render and fields to ignore.
Awesome progress PT_ :) Keep working on it, you can do it!! :thumbsup:
Indeed, I test my algorithm to render only a part of the field to reduce time. The results are pretty good, although these are without the time needed to get the bounds, and not the entire screen:
Old: 17659450 clock cycles
New: 4131812 clock cycles
Not bad, but I fear still too slow :(
U went from 17.7million to 4.1million, that's awesome!! :D
How much further would you need to reduce it?
also can omething be done by reducing the size of the ingle graphic tiles...?
Indeed, the increasing speed is pretty nice, and it's almost the entire loop, I think filling the entire screen would take up 5 million clock cycles, which leads us to an FPS of almost 10. And I think not decreasing, but increasing the tile size would decrease the time to fill, as then clipping can be done in 1 time and then display, now it must clip 4 times.
Nice work PT_! :)
Some comments to help speed things up:
Don't redraw the status bar every frame. Change the clipping region so you can update it only when necessary.
Don't erase the background with a fill routine. Use a background tile and have your rendering routine behave similar to a regular tilemapper.
Anywho, good luck! :)
well if you're at 10FPS right now and you still use non-optimized rendering in some parts, then I dont see any problem :D
I guess that should be fast enough for the game ;)
I've tried implementing what Mateo said, and I made a small routine that displays only the tiles, but it's still 6768350 cycles :(
If anyone can optimize it, I would be super happy :)
DrawField:
xor a, a
sbc hl, hl
ld (TilesYPosition), hl
push ix
ld b, 30
DisplayEachRowLoop:
push bc
ld ix, -20
bit 0, b
jr z, +_
lea ix, ix+16
_:
TilesYPosition = $+1
ld hl, 0
push hl
DisplayRowOfTilesLoop:
ld (AmountOfTilesLeft), a
push ix
ld hl, _tile_test
push hl
call gfx_TransparentSprite
pop hl
pop hl
lea ix, ix+32
AmountOfTilesLeft = $+1
ld a, 0
inc a
cp 11
jr nz, DisplayRowOfTilesLoop
pop bc
pop bc
ld hl, (TilesYPosition)
ld de, 8
add hl, de
ld (TilesYPosition), hl
djnz DisplayEachRowLoop
pop ix
ret
Disclaimer: i've never written ez80 code
This doesn't use any window logic as somehow on IRC you couldn't tell me if you use that or not :P
Also this is all untested
Also I've never written ez80 asm
; this routine assumes tileMap is the tilemap, spriteSheet the spritesheet and screenBuf the screen buffer
; sprites are one byte in the tilemap
; tilemap is 255x255 tiles
; sprites are 32x16
DrawField:
ld hl,tilemap
ld de,screenBuf
ld b,255
_:
ld c,255
__:
ld a,(hl)
push hl
push de
push bc
call DrawTile
pop bc
pop de
ld hl,32
add hl,de
ex de,hl
pop hl
inc hl
dec c
jr nz,-__
; we need to fast-forward de ofc a bit more now
push hl
ld hl,255*16
add de,hl
ex de,hl
pop hl
djnz -_
ret
; ofc this could be inlined, it's just way easier to think about my code this way. If you inline this you save a few more cc. You can also unroll this
DrawTile:
push de
; let's first grab hl
; offset stuff times 512 = 32*16 = 8*16*4 = $80 * 4
ld h,a
ld a,$80
ld l,a
mlt hl ; h*l
add hl,hl ; *2
add hl,hl ; *4
ld de,spriteSheet
add hl,de
; ok our buffer thing is now in hl
pop de
ld a,16
_:
; copy a row
ld bc,32
ldir
; progress to the next row
ex hl,de
ld bc,(255 - 1)*32
add hl,bc
ex hl,de
dec a
jr z,-_
ret
He would need transparency but it is also a good idea to utilise a purpose built tile drawing routine as opposed to a general sprite routine.
8 FPS would definitively be fine. 5-7 would be ok as well but only as long as keypresses are registered properly at any time (eg no missed keypresses) and processed immediately rather than one frame later.
are you kidding me soru, you learned ez80 within one day... :ninja:
Got a non-working homescreen done! :D
(http://i.imgur.com/e3I3joA.gif)
Total size of the images is around 15K.
looks really nice :)
how's the speed going, did you make further profgress in speeding up the rendering? :)
Quote from: p2 on January 27, 2017, 06:02:05 AM
are you kidding me soru, you learned ez80 within one day... :ninja:
ez80 asm is pretty similar to u80 asm.
In fact, once you learn one architecture a different one will be easier to pick up. AVR isn't that hard, either, IMO......
Quote from: Sorunome on January 28, 2017, 12:54:06 PM
Quote from: p2 on January 27, 2017, 06:02:05 AM
are you kidding me soru, you learned ez80 within one day... :ninja:
ez80 asm is pretty similar to u80 asm.
In fact, once you learn one architecture a different one will be easier to pick up. AVR isn't that hard, either, IMO......
I thought it was called z80 after Zilog, the producers...?
u80... <_<
I like the title screen, but you might want to do something about those white text artifacts. :P
I will remove some :)
I've uploaded all the files to Github, in case anyone wants to help or give tips.
https://github.com/PeterTillema/Age-Of-CEmpires-I
Quote from: PT_ on February 01, 2017, 07:47:47 PM
I will remove some :)
I've uploaded all the files to Github, in case anyone wants to help or give tips.
https://github.com/PeterTillema/Age-Of-CEmpires-I
I know this is only remotely related, but.... https://github.com/PeterTillema/Age-Of-CEmpires-I/blob/master/index.php#L84
It is bad practice to place ?> all at the end of a PHP file, as following whitespace would be automatically outputted. Now, if you had your PHP script generate an image or something the following whitespace would result in a corrupt image.
There are more examples where having ?> at the end with additional whitespace leads to weird bugs, hunting them down can be very nasty. So just omit ?> if it's all at the end of the file ^.^
On a side note, if your strategy game idea ended up not working, those large building sprites would still be great in an RPG. Many RPGs used isometric view so you could make an RPG based around Ages of Empires.
That doesn't mind at all. If I can't get a reasonable FPS with AoCE, I can't reach it either with a similar RPG (-_(//));
Well, with an RPG you only need to move one character around rather than 15-20 units per frame with pathfinding and everything :P. Regardless of what you decide, I'm really looking forward for what you can come up with in the future and I'm hoping you can solve remaining speed issues. :)
Is there any update on the framerate
@PT_ ? :)
Well, yet not, but I decided to add a border around the frame, such that I don't need clipping. TheMachine already wrote a fast routine to display an isometric tile, and I optimized it a little bit more, which should be very fast.
AoCEDisplaySprite:
; Routine written by TheMachine02 and optimized by me
; Input:
; Arg0: pointer
; Arg1: x
; Arg2: y
; Bytes: 213 bytes
; Time:
ld iy, 0
add iy, sp
ld c, (iy+9)
ld b, 160
mlt bc
ld hl, (0E30014h)
add hl, bc
add hl, bc
ld bc, (iy+6)
add hl, bc
ld bc, 15
add hl, bc
ld de, (iy+3)
ld c, 2
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256+2-6
add hl, bc
dec b
ld c, 6
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256+2-10
add hl, bc
dec b
ld c, 10
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256+2-14
add hl, bc
dec b
ld c, 14
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256+2-18
add hl, bc
dec b
ld c, 18
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256+2-22
add hl, bc
dec b
ld c, 22
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256+2-26
add hl, bc
dec b
ld c, 26
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256+2-30
add hl, bc
dec b
ld c, 30
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256+1-32
add hl, bc
dec b
ld c, 32
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256-1-30
add hl, bc
dec b
ld c, 30
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256-2-26
add hl, bc
dec b
ld c, 26
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256-2-22
add hl, bc
dec b
ld c, 22
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256-2-18
add hl, bc
dec b
ld c, 18
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256-2-14
add hl, bc
dec b
ld c, 14
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256-2-10
add hl, bc
dec b
ld c, 10
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256-2-6
add hl, bc
dec b
ld c, 6
ex de, hl
ldir
ex de, hl
inc b
ld c, 320-256-2-2
add hl, bc
ex de, hl
ldi
ldi
ret
so using the modified display algorythm and witout the clipping the rendering speed should be increased, right? :)
Really looking forward to hear you talking about something like 60fps :thumbsup:
Time for some small updates. Last days I've been busy with optimizing the routine to display all the tiles at the screen. I've decided to add a border around the field, to avoid clipping, and with the help of both grosged and TheMachine, I got it down to like 711751 cycles, which is really good ;D When there are no more optimizations left, I will start with other stuff, such as the edges of the field and scrolling :)
Entire code (DrawFieldStart = mpShaData, AoCEDisplayIsoTile = cursorImage):
DrawField:
scf
sbc hl, hl
ld (hl), 2
; Speed: 722161/721349/711751 cycles
ld hl, -3
jp mpShaData
DrawFieldStart:
add hl, sp
ld (TempSP2 - AoCEDisplayIsoTile + cursorImage), hl
ld hl, (currDrawingBuffer)
ld de, 15
add hl, de
ld (startingPosition - DrawFieldStart + mpShaData), hl
ld de, 8*320
ld b, 29
DisplayEachRowLoop:
bit 0, b
exx
startingPosition = $+2
ld iy, 0
ld a, 10
jr nz, DisplayRowOfTilesLoop
dec a
lea iy, iy+16
DisplayRowOfTilesLoop:
ld hl, _tile_test \.r2
call cursorImage
lea iy, iy+32
dec a
jr nz, DisplayRowOfTilesLoop
exx
add hl, de
ld (startingPosition - DrawFieldStart + mpShaData), hl
djnz DisplayEachRowLoop
ret
DrawFieldEnd:
.echo DrawFieldEnd-DrawFieldStart
AoCEDisplayIsoTile:
; Thanks a lot to TheMachine02 and grosged for help and optimizations!
; Input:
; IY = pointer to output
; HL = pointer to iso sprite
;
; Bytes: 168 bytes
; Time: 2558 cycles
lea de, iy
ld ix, 0
lea bc, ix+2
add ix, de
ld sp, 320
ldir
add ix, sp
lea de, ix-2
ld c, 6
ldir
add ix, sp
lea de, ix-4
ld c, 10
ldir
add ix, sp
lea de, ix-6
ld c, 14
ldir
add ix, sp
lea de, ix-8
ld c, 18
ldir
add ix, sp
lea de, ix-10
ld c, 22
ldir
add ix, sp
lea de, ix-12
ld c, 26
ldir
add ix, sp
lea de, ix-14
ld c, 30
ldir
add ix, sp
lea de, ix-15
ld c, 32
ldir
add ix, sp
lea de, ix-14
ld c, 30
ldir
add ix, sp
lea de, ix-12
ld c, 26
ldir
add ix, sp
lea de, ix-10
ld c, 22
ldir
add ix, sp
lea de, ix-8
ld c, 18
ldir
add ix, sp
lea de, ix-6
ld c, 14
ldir
add ix, sp
lea de, ix-4
ld c, 10
ldir
add ix, sp
lea de, ix-2
ld c, 6
ldir
add ix, sp
lea de, ix
ldi
ldi
TempSP2 = $+1
ld sp, 0
ret
AoCEDisplayIsoTileEnd:
If you see optimizations, feel free to post it :P
Looks great! I can't wait for updates :)
Are you kidding me..... <_<
Got smooth scrolling working! :)
(http://i.imgur.com/vBAkfSv.gif)
It can actually be like 3 or 4 times faster, I disabled it for now to show it ;)
well that doesnt look too bad speed-wise ;)
buuut how big will the actual houses be...?
I know this would kill most of your work, but I think it'd be pretty cool to have really tiny houses, just like in ur scrolling demo....
Then you could fit enough on the screen at once ^.^
but idk if you would even be able to distinguish the houses... :/
Woah this looks smooth as hell. Awesome so far. I am definitively curious about how it will be with the buildings :)
This is the real speed :)
(http://i.imgur.com/Kwr1jgy.gif)
That is very spicy :)
Keep it up!
Quote from: PT_ on February 18, 2017, 07:59:21 PM
This is the real speed :)
(http://i.imgur.com/Kwr1jgy.gif)
awesome. Hopefully you can add new stuff without much hassle
Woooow nice O.O
How long do you think until u got a demo with the first house? :) I'm really curious about the speed once it's implemented ^.^
I have this week holiday, so hopefully I can add buildings rendering ^.^ But first I need to add something such that the borders are visible (i.e. a black tile instead of the grass/test tile) :)
yeah I had some problems with invisible tiles a they weren't updated in my game...
basically undefined areas were an afterimmage of the last stuff displayed there, caused by scrolling. :ninja:
lucky for me, in a RPG I don't need a background as long as all tiles are defined and there are no holes in the map ^^
but for an isometric game like yours you sadly do need a border :/
will you simply make it black, like the original AoE game? :)
I always wondered how map boundaries are done in isometric mappers. Is the map array/matrix rotated 45%? In such case I bet it wouldn't be too hard.
A tutorial on that as well as on isometric mapping in general would be really nice :)
Edges work!!!!!!
(http://i.imgur.com/98r6Mfz.gif)
Now the optimizing part begin, it's currently 908839 cycles :)
looks nice
i'm really amazed how you manage to improve the program and add more stuff to it, yet make it faster like the 20th time in a row now xD
But I have to admit the edge rendering really IS impressive, thinking about how fast you did it ^.^
you forgot to mention those 908839 cycles are 53 fps ;)
Wow, this is very smooth and professional :3=
impressive result :thumbsup:
Got something done.... it should be somehow related to placing resources and trees... :P
(http://i.imgur.com/RLYYpea.gif)
the speed of this "animation" indeed is impressive, but I'm not sure if that's in the original game as well... ;)
Didn't you plan to make it as close to the original as possible? :)
Alright, it was supposed to be this:
(http://i.imgur.com/Z3s0sMm.png)
The green pixels are trees, the black pixels not :P The map size will be either 128 or 144, not sure yet.
Nice speed. :) I can't wait to see the result with real sprites.
I suppose rendering and the AI will take up most of the runtime, whith focus on unit handling, so the actual mapsize should only have a minor effect on the game speed :)
If I had to guess, I'd say twice the mapsize would mean a 10-15% slowdown, thinking about the MASSIVE task of rendering and unit movements ;)
@P_T you might want to take a look at that:
https://sourceforge.net/projects/aoe2ar/
it's a graphics mod for AoE2, which looks pretty nice. I suppose you could copy some of those buildings right from that image (they're almost identical with the original tiles)
and this should teach you how to directly extract the original tiles:
http://steamcommunity.com/sharedfiles/filedetails/?id=190070326
Quote from: p2 on March 02, 2017, 09:39:17 PM
@P_T
Who is that? <_<
It is supposed to work correctly :P
(http://i.imgur.com/OMBJLQq.gif)
hmmm is the grass overwriting//covering the stone or is there a bug in loading the map data?
I would susperct the first.
To test this, you may want to add 100% transparent pixels to the grass tiles to see if there's stone below it ;)
but as I dont know ur code I cant tell u how to fix it sry xD
Finally it works!! :D
(http://i.imgur.com/bWx3qoN.gif)
This ain't Minecraft, why's there Gold blocks?
What was the bug and how did you fix it? I'm curious :)
Good job! :)
TREES! MORE TREES! WHO WANTS SOMETHING ELSE THAN TREES???
(http://i.imgur.com/ZJubovs.png)
O.O
Looking very nice PT_! That seems like a lot of trees; looks like I'll need a mill hehe. :P
Nice trees, but it seems there is snow under them :P
looks nice, PT_ :thumbsup:
I think what would be nice is Fields (super easy, only 1 single layer) and maybe indeed a windmil (animated, wooooo) :w00t:
I suppose sheep (and other less important) units will come later as the require entire different code stuff ;)
Many many thanks to JamesV, who handed me his fading routine! :) I modified it a bit, which results in this:
(http://jonbush.net/img/i/ZmRiYzIx.gif)
wow, this looks really awesome!! :D
btw it's been 10 days since ur last updates, have you made any progress on the game engine in the meantime? :)
Nope, I've sadly not enough time to program that much, I've lot of other stuff going around.
That transition is pure amazingness :)
That is an epic transition! I hope it is only first time though, it is kinda long to be used every time the user launches the game.
You need to make a .001% chance that if you cut down a tree, an ent will come and kill your empire! Anyway... It looks like it is coming along nicely. Keep up the great work!
He could always make the transition shorter or make it end instantly if a key is pressed
I like the fading in and out :3
The text sprites are updated as well:
(http://i.imgur.com/YqMEft0.png)
Good job :). I wonder if you will be able to remove the white artifacts around the main title or make its background like a piece of paper or something?
Actually that's a good idea.
In the original game, both the tech tree and the credits screen had beautiful backgrounds that would probably fit perfectly here :)
I'll see if I can provide screenshots later (but those would be resized as Im using wine...)
this would be the nice background AoE2 uses in the GUIs:
(http://www.forgottenempires.net/wp-content/uploads/2012/12/AI_Selection.jpg)
But thinking about this agian, I think it probably wouldn't look that good for the knight, he looks better n a black background... :/
btw
@PT_ how's the game? Did you have some time to worke on it again? :)
No, I'm way too busy to work on it, I need to program AoCE, ICE, SC, jsTIfied, Happietaria (pop-up restaurant in my city), and that is outside school and personal stuff <_<
Holy Cow :ninja:
sorry for asking... >.<
I really hope tho this doesn't mean the end of the project, it was really promising :) <3 Hope u can get back to it later :)
Yeah I agree. Life and school (and work) can get pretty hectic sometimes, though >.<
I didn't know you were in charge of SourceCoder and jsTIfied, though.
Quote from: DJ Omnimaga on March 27, 2017, 09:24:23 PM
I didn't know you were in charge of SourceCoder and jsTIfied, though.
Yep, I am, I've fixed some bugs in SC, and I'm mainly responsible for adding CE support to jsTified *laughs* and fix some bugs :P
Oh lol I see now. I was surprised that jsTIfied still had no CE support after so long actually, but again Kerm might be very busy with Doors CE 9 and other things.
look good :thumbsup:
what do you want the program to do ? ???
Quote from: Alvajoy123 on April 13, 2017, 02:50:42 PM
look good :thumbsup:
what do you want the program to do ? ???
Playing Age of Empires...? <_<
Lmao :blah: :blah:
Yeah Alvajoy you really need to check the first post of topics before replying to be honest (or the other posts if the first post has minimal info and no screenshot)
So I decided to take a break with this project. I've currently too many things around, my study isn't going well, and I've a lot of programming projects going. Since this project is pretty hard, and I need to overcome some hard things, I decided to move away from this. Don't worry, of course I will still keep it, in case I'm less busy, and I'm in the mood again to work on this!
Sorry to hear. Studies should be a priority, though. Glad it's still alive by the way. Take your time :3= (You can probably work on smaller projects if you have some free time for the time being)
EDIT: Topic locked per
@PT_ request:
QuoteP_T DJ: can you maybe lock the AoCE topic, until I ask to open it again? 5:53:10 PM
DJ Omnimaga i can probably do that 5:53:20 PM
DJ Omnimaga well actually 5:53:23 PM
DJ Omnimaga i think you can, right? 5:53:27 PM
P_T I don't want to answer many questions, or whatever, and people complaining that I need to work on it 5:53:30 PM
Sorry to hear :/
I really hope you can continue working on it later :love:
And good luck with ur other projects as well :)
nüf <3
I gonna work on it again! I'm less busy these days, and when Mateo said ConvPNG can export to appvars, I (accidentally) said I can continue AoCE, so now it's finally time to get some nice progress :)
Awesome. Glad you are less busy and have more free time for yourself :)
I assume that appvars will be able to be archived like in Oiram, right?
Yes, you don't have enough RAM for all my sprites ;)
Okay, now that I said I would work again on it, it's time for some more details, changes, etc.
- Buildings will get a complete overhaul, they now will be in the shape of isometric tiles, rather than just buildings. This allows buildings to be drawn at the same time as a tile, it just pretends it's a tile, so no lag.
- I will just make it like normal games, just double-buffering. However, it's unnecessary to redraw the tiles + buildings each frame, only when you move around you need to redraw it. That is why I gonna use a third buffer with the temp tiles + buildings. Instead of redrawing all the tiles and buildings, it just copies the temp buffer to the buffer, which would save much time. However, moving would be slower in this case.
- Each player will be limited to either 75 or 100 puppets. This is mainly to not cause lag by updating too many puppets, and to save RAM. Each puppet (soldier/volunteer/whatever) has some properties, i.e. health, upgrades, location, business and more.
- When you send a puppet to a certain location, it first finds it's way to it, and then it will store the parth somewhere in RAM. Thus, when walking, he only needs to get the next location instead of recalculating the path everytime.
- My minimum FPS would be 10, if I can't get the framerate about 10, I won't continue it, then it's not playable.
- More are coming, once I'm busy with this project :D
Scrolling works again, as well as double buffering :)
(http://i.imgur.com/DQ8Ngr3.gif)
Are the graphical glitches CEmu or the game?
Looks great btw :D
I wish it was CEmu, but I have to fix it myself (-_(//));
the speed is really impressive, I'm sure you can fix it! :)
Great work so far :thumbsup:
Thanks :)
This screenshots is more than 60 FPS, but that will drop rather fast I guess :P
true, drops during development process have to b e expected, but that'S a solid framerate you're starting with, so even if it'D drop by 50% it'd still be playable :)
I think I would end with like 15 FPS. Doing the events of all the puppets takes the most time, I think. Hope to make good progress these weeks :D
This looks even better :P
(http://i.imgur.com/mLwq75l.gif)
Are those.. random rocks? and the blue thing is as building, yes? Looking amamzing!
This is epic. Reminds me a lot of those late 90's PC strategy and RPG games so the nostalgia is kicking in right now :D
I'm SUPER happy to announce that my pathfinding algorithm works for 99%! It uses A* to find the path, and once it hits the end tile, it just stops, rather than doing the reverse, to find the actual path in the closed list. The speed is now 28K cycles for this path:
(https://koenig-media.raywenderlich.com/uploads/2011/09/Cat-Maze_9.jpg)
Not that bad, I would say :)
Here (https://pastebin.com/p9sYiRxV) is the algorithm, any optimization is welcome :D
That's, like, amazingly amazing, and I am really excited for this..
#hypetrain!!
Good news! I decided to pick this up again, and I've made good progress with the graphics. Luckily I found the complete spriteset, so I've pretty much finished all the graphics! There's not much to show though, but I've changed the entire codebase, added all the graphics, and improved some things. I have good hopes the speed will be above 10FPS, which was my original target. This week and the next year (heh, that sounds cool :P) I will work on displaying the map, buildings, units, and after that the actions, like fighting, moving and whatever. Stay tuned! :)
(https://i.imgur.com/0hjyQiM.png)
As you see here, there's a black border around the map. I will write some code to make it pretty much fullscreen, except the top bar with the resources and population, and a bar at the bottom with some key actions.
Great news. This looks good by the way :)
Here's some more general information about the sizes and whatever:
- All the buildings and unit for each age will be stored in 1 appvar (I still need to check if this is possible for age III, since that age has too much buildings). This means you always have transfer at least 4 appvars
- There will be another appvar with all the standard sprites which is needed in every age, such as cursors, foundation, rubble etc. This is the 5th appvar.
- The last appvar contains the sprites for the main menu, which is 34kB in total. This is the last and 6th appvar. In order to get AoCE running, you need to transfer 6 appvars and 1 program to the calc :P No worries though, everything can be put into the archive, such that it won't take up RAM.
- Looking at this (https://pastebin.com/kZPbSG2t) pastebin, you see that age 4 will take up the most RAM, in total 83686 + 37591 = 121277 bytes. This simply doesn't fit into free RAM, excluding 32768 bytes for the map data, all the units, and AoCE itself which will be around 30kB I hope. Thus, AoCE will always backup RAM and use full RAM, which should be enough. I've spend 2 days to get this fully working, and it finally works (kinda). Here are some screenshots of the process :P
(https://i.imgur.com/xCaXdVe.png) (https://i.imgur.com/hpzgnCe.png) (https://i.imgur.com/FFTcYHo.png)
- Meanwhile, the main menu is already fixed, and I still need to add some code to load sprites from appvars to the RAM.
And that's it! I'm working super hard to get everything working so stay tuned. If you really want to follow the process, join #aoce-dev on EFnet :)
Uh oh, I need help :( I don't really know how to draw all the units. I can't draw them after the tilemap, because then they will be displayed in front of everything, which is clearly not right. I can't draw them before the tilemap either, then the tiles will overdraw them. So the only solution is to display them together with the tilemap... which is almost impossible. Since they are constant moving, my idea was to put all the units in an array, with their coordinates, health, attack points etc.. but how do I draw a unit at a certain tile? Going through the entire list all the time is way too slow :(
I dont really know how ur game works, but I'd go for the following option:
- split houses in front (that can be overlapped by units - bottom half of house tiles) and back (that will overlap units - top half of tiles)
- draw background
- draw bottom tiles of houses
- draw units
- draw top tiles of houses
they should overlap each other and end up being accurate. Think this will work for you?
Hey
@p2 you wanted 60fps right? Here you go:
(https://i.imgur.com/d6QezNu.gif)
:love:
OMG, that speed! O.O How?
Nope :trollface:
Seriously, this is cool.
Nope, no Mateo this time :trollface:
Time for a quick update! I selected and edited all the sprites for the units AoCE has, and managed to fit it in 2 (full) appvars. This means that in the final game you need to transfer 8 appvars + AOCE to your calc :roll: Luckily everything can be put in the archive, which means you won't lose RAM. Outside of that, if AoCE crashes for some reason (which might be very likely once I start adding stuff..), there is no memory leak, and your entire RAM is saved. :)
(https://i.imgur.com/20BS5y4.png)
Darn that's a lot of big files O.O, this means the game will be very elaborate ^^ . I'm happy the CE has more RAM and flash for graphics.
Quote from: xlibman on February 03, 2018, 05:04:01 PM
Darn that's a lot of big files O.O, this means the game will be very elaborate ^^ . I'm happy the CE has more RAM and flash for graphics.
Yep ^^ There are a lot of sprites, 42 for each unit, times 22 units = 924 sprites in total. Luckily they are not that large, otherwise you would have even more appvars. But indeed, you can keep all in flash :)
AoCE is now an app! :D
(https://i.imgur.com/Y50JwX2.png)
I entirely switched to fasmg, which was a horrible move, but now it's much better. You don't need spasm anymore to build it, just download the C toolchain.
Looks great :D
Wow! Framerate and camera speed look really great! I hope that doesn't change too much once you add more moving parts and data points like units, etc.! I love the isometric style, since it brings me back to playing these games when I was younger. Can't wait to see this release!
/me just fell in love... :ninja:
I still miss me sheep but it looks really fantastic, can't wait for the next update!! :love:
The sheep are coming :P
It has been almost 2 months, but I'm working on it again. Sadly, I discovered that not all the units were included in the 2 units appvars, and I had to make 3 of them (60kB each...). I've done some work behind-the-scenes, which include not removing itself from userMem (because it's an app) and some more cleanup things (huge thanks to jacobly!). I'm currently busy with both teamcolors in buildings and units and displaying units, which is gonna be a pain, but I need to do it :/
How do you/ can you place units? Also, can you make an option to skip past the fade in/out intro? It's cool, but when you want to start playing, it makes you wait :(
Hmm it looks nice. Does the CE really have enough memory for such detailed sprites?
Quote from: Caleb Hansberry on April 18, 2018, 04:24:42 AM
Hmm it looks nice. Does the CE really have enough memory for such detailed sprites?
IIRC, AOCE puts everything in the Archive, and then fills most of the RAM to run. I think that there shouldn't be that much of a problem, because with OS 5.3, you can run archived programs without unarchiving them. SO, you'd keep things in archive, and AoCE would have tons of space to run in. Also, I think some of the stuff is stored in an appvar in archive to take up less space.
Quote from: jcgter777 on April 18, 2018, 04:30:14 AM
Quote from: Caleb Hansberry on April 18, 2018, 04:24:42 AM
Hmm it looks nice. Does the CE really have enough memory for such detailed sprites?
IIRC, AOCE puts everything in the Archive, and then fills most of the RAM to run. I think that there shouldn't be that much of a problem, because with OS 5.3, you can run archived programs without unarchiving them. SO, you'd keep things in archive, and AoCE would have tons of space to run in. Also, I think some of the stuff is stored in an appvar in archive to take up less space.
Not entirely true. Everything will be put in flash, true, but all the assembly programs need to be unarchived to run (except apps). AoCE backups RAM and then clears it, then it puts its main code in RAM, sprites, map data, buildings (and total of about 150kB) and the remaining space is for dynamically loading units :)
Quote from: PT_ on February 10, 2018, 07:57:34 PM
AoCE is now an app! :D
(https://i.imgur.com/Y50JwX2.png)
I entirely switched to fasmg, which was a horrible move, but now it's much better. You don't need spasm anymore to build it, just download the C toolchain.
The speed *.*
Quote from: xlibman on April 18, 2018, 11:06:00 AM
Quote from: PT_ on February 10, 2018, 07:57:34 PM
AoCE is now an app! :D
(https://i.imgur.com/Y50JwX2.png)
I entirely switched to fasmg, which was a horrible move, but now it's much better. You don't need spasm anymore to build it, just download the C toolchain.
The speed *.*
I know right, except I can't promise it will be that fast when everything is added :trollface: Also, you can look at the amount of wood, it increases one per frame.
So.... teamcolors works! :D
(https://i.imgur.com/vb9Apr1.png)
Credits to Runer112 who figured out a nice format to quickly edit all the teamcolor pixels instead of loading the building twice.
Good news! Units work! Bad news! Units don't work! :P
(https://i.imgur.com/wW8yx72.png)
There's snow in the second tree. O.O
Quote from: xlibman on May 17, 2018, 09:59:09 PM
There's snow in the second tree. O.O
Yep, your eyes are properly working :)
That tree caught my attention because of the grass map. I thought it was a glitch or something xd
I'm more than happy to say that units now work properly! As far as I could test, sorting them based on the offset in the isometric tile works, teamcolors work, offsets work, and they don't jump when scrolling, like in the post above :P This means basically every game-drawing is done, and I can move to either optimizing or start with the actual gameplay.
(https://i.imgur.com/71mMXvP.png)
An image says more than thousands words 5 months programming :P
(https://i.imgur.com/mtva8Ij.png)
Looks really really nice PT_ :)
I suppose it supports only the red and blue teams?
Is your current implementation of units already capable of doing animated sprites (walking animations) or do you probably plan not to use animated tiles at all? Not sure how much the hardware can handle...
Quote from: p2 on May 24, 2018, 08:47:23 PM
Looks really really nice PT_ :)
I suppose it supports only the red and blue teams?
Is your current implementation of units already capable of doing animated sprites (walking animations) or do you probably plan not to use animated tiles at all? Not sure how much the hardware can handle...
Nope, it can handle only 2 teams, but you can choose whatever color you want, because it's just changing the palette entries :)
Indeed, walking will be animated, it consists of 3 sprites per direction. Attacking is not animated though, otherwise we have 2 new appvars :trollface:
Both scheduling events (necessary for disappearing units when they're dead for example) and removing dead units works now :)
(https://i.imgur.com/SuZDcgn.png)
Are the images a lot more detailed than they have to be? It does look great but if it makes it enormous...
This is the beauty of color palettes and the ability to change them. To save space when units die or gets healed, all you have to do is dim their palettes to red, blue or whatever, and in the case of dying units, if you plan to have maps where only 1 floor tile is used at a time (for example, grass), then you could simply make the unit turn red then fades to grass colors to simulate translucency when it dies. (kinda like how Final Fantasy VII enemies die)
Quote from: xlibman on July 16, 2018, 01:58:11 PM
This is the beauty of color palettes and the ability to change them. To save space when units die or gets healed, all you have to do is dim their palettes to red, blue or whatever, and in the case of dying units, if you plan to have maps where only 1 floor tile is used at a time (for example, grass), then you could simply make the unit turn red then fades to grass colors to simulate translucency when it dies. (kinda like how Final Fantasy VII enemies die)
That doesn't work, because the units use the same palette as the buildings, trees, game, etc.