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 ) I will work on displaying the map, buildings, units, and after that the actions, like fighting, moving and whatever. Stay tuned!
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.
Cool! Why does this use numpad-arrow control instead of regular arrow control? Or is that for the cursor?
Yep, I removed the cursor for now, because it was way too big and there are better things to do.
Also, 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 No worries though, everything can be put into the archive, such that it won't take up RAM.
Looking at this 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
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
Forgive me if this seems dumb, but couldn't you simply draw the units+trees+buildings all in a single loop, and draw them from the top of the map down? I mean this is isometric 3D, and I believe that's how people typically do it with the layering.
Why would drawing both the map and the units at the same time be impossible? Is it because drawing the entire map in one go is more efficient?
Regarding drawing units that are not covered by anything:
If you only want to redraw part of the screen at each frame, I'd suggest animating the units (given than the user does not scroll the map, otherwise you'd be back at step 1 and re-drawing it entirely) by saving the screen rectangle on which you're about to draw each unit, so that you can "cancel" the drawing by restoring this rectangle when you want to draw the next animation frame. (In this case, make sure you cancel the drawing of each unit in reverse order.) I don't know if it's technically possible, but I think it'd be fairly efficient.
Another way would be to redraw all the tiles and units which are totally or partially covered by your unit, and those that they themselves cover, all the way up to the top of the screen (in reverse order, of course), but it may end up even slower than redrawing everything if not careful enough (ie. some things might be redrawn twice).
For units that are covered, the simplest way would be to redraw what's covering them once the new frame is ready, but you'll end up redrawing things from top to bottom (as CodertheBarbarian suggested).
The most optimized idea which I can come up with right now is to draw "static" objects (eg. ground, non-animated buildings, etc) and "dynamic" objects (roughly animated things) to different layers. Then, when you want to do the regular update the screen, you'd redraw the dynamic layer and perform the layer merge with the static layer when copying it to VRAM. This way, you only have to perform the merge on the animated areas, which I think is pretty efficient.
I have almost no knowledge of the platform however, so I hope these suggestions make sense.
Edit: I even forgot to tell how great this project looks. I'm amazed that so much can be achieved with pure assembly. Good job!
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum