Join us on Discord!
You can help CodeWalrus stay online by donating here.

[ti-84+ce]Age of CEmpires I

Started by PT_, January 03, 2017, 08:22:00 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Dream of Omnimaga

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.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

p4nix

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.
  • Calculators owned: fx9860GII (SH4)

PT_

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 :)

p4nix

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 ;)
  • Calculators owned: fx9860GII (SH4)

PT_

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:

p4nix

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 ;)
  • Calculators owned: fx9860GII (SH4)

E37

@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!
  • Consoles, mobile devices and vintage computers owned: Ti83,Ti84!
I've never finished a project, there is always a way to improve!
What's my calc's name? Convert $37 to decimal. Look up that element in the periodic table. Then take the abbreviation of that element and you have it!
Look! A slime!    <(^.^)>

123outerme

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!
  • Calculators owned: TI-84+CSE, TI-nspire Clickpad, TI-84+SE

E37

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!
  • Consoles, mobile devices and vintage computers owned: Ti83,Ti84!
I've never finished a project, there is always a way to improve!
What's my calc's name? Convert $37 to decimal. Look up that element in the periodic table. Then take the abbreviation of that element and you have it!
Look! A slime!    <(^.^)>

Dream of Omnimaga

Awesome speed increase PT_ :D
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

p2

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 ;)
  • Calculators owned: ti-83+, ti-84+, ti-84+, ti-84+se, ti-84+se(te), ti-nsphire, ti-nsphire CAS, ti-nsphire CX-CAS, ti-voyage, ti-voyage, Who reads this list anyways...?
Anyway war sucks. Just bring us your food instead of missiles  :P ~ DJ Omnimaga (11.10.2016 20:21:48)
if you cant get a jframe set up, draw stuff to it, and receive input, i can only imagine how horrible your game code is _._   ~ c4ooo (14.11.2016 22:44:07)
If they pull a Harambe on me tell my family I love them ~ u/Pwntear37d (AssangeWatch /r/)
make Walrii great again ~ DJ Omnimaga (28.11.2016 23:01:31)
God invented the pc, satan the smartphone I guess ~ p4nix (16.02.2017 22:51:49)

PT_

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 :)

p2

tl;dr  :ninja:
but I really hope It wll help you speeding it up. Good luck PT_  :thumbsup:
  • Calculators owned: ti-83+, ti-84+, ti-84+, ti-84+se, ti-84+se(te), ti-nsphire, ti-nsphire CAS, ti-nsphire CX-CAS, ti-voyage, ti-voyage, Who reads this list anyways...?
Anyway war sucks. Just bring us your food instead of missiles  :P ~ DJ Omnimaga (11.10.2016 20:21:48)
if you cant get a jframe set up, draw stuff to it, and receive input, i can only imagine how horrible your game code is _._   ~ c4ooo (14.11.2016 22:44:07)
If they pull a Harambe on me tell my family I love them ~ u/Pwntear37d (AssangeWatch /r/)
make Walrii great again ~ DJ Omnimaga (28.11.2016 23:01:31)
God invented the pc, satan the smartphone I guess ~ p4nix (16.02.2017 22:51:49)

Dream of Omnimaga

Good luck PT_. Hopefully this alleviates your speed problems. :)
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

PT_

#44
'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:


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:

(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:

Powered by EzPortal