WIP: Wizard of Wor
Moderator: Moderators
Re: WIP: Wizard of Wor
Damn, Kasumi...you might be right
-Thom
-Thom
Re: WIP: Wizard of Wor
What I tend to do is take the next major task and then repeat the following iteration:
1. Find the first task on the list that I expect to take longer than 15 minutes.
2. If one exists, divide it up into smaller tasks.
3. If a task was split, and there are fewer than 12 tasks, go to step 1.
1. Find the first task on the list that I expect to take longer than 15 minutes.
2. If one exists, divide it up into smaller tasks.
3. If a task was split, and there are fewer than 12 tasks, go to step 1.
Re: WIP: Wizard of Wor
if I could, I'd hug you guys. Thanks.
-Thom
-Thom
Re: WIP: Wizard of Wor
Am back on WoW, have been so busy lately, and health issues caused me to have to take a break.
Right now, I am refactoring the code, and splitting bits out into seperate files.
In the main .h, I have a set of variables defined in my zeropage bss segment. The problem seems to be when I try to use them in other files. It seems:
Produces an address mismatch:
For some reason, it's ignoring my #pragma and using .import instead of .importzp :/ wtf? I know I'm doing something silly...
What's going on?
-Thom
Right now, I am refactoring the code, and splitting bits out into seperate files.
In the main .h, I have a set of variables defined in my zeropage bss segment. The problem seems to be when I try to use them in other files. It seems:
Code: Select all
#pragma bssseg (push,"ZEROPAGE")
extern unsigned char spr,i,frame_cnt;
#pragma bssseg (pop)
Code: Select all
ld65.exe: Warning: Address size mismatch for `_frame_cnt': Exported from wow.o, wow.s(25) as `zeropage', import in attract_monsters.o, attract_monsters.s(31) as `absolute'
ld65.exe: Warning: Address size mismatch for `_i': Exported from wow.o, wow.s(18) as `zeropage', import in attract_monsters.o, attract_monsters.s(30) as `absolute'
ld65.exe: Warning: Address size mismatch for `_spr': Exported from wow.o, wow.s(24) as `zeropage', import in attract_monsters.o, attract_monsters.s(29) as `absolute'
What's going on?
-Thom
Re: WIP: Wizard of Wor
err, turns out I literally had to do this:
Which is....really fucking awkward...but okay.
-Thom
Code: Select all
extern unsigned char spr;
#pragma zpsym("spr")
extern unsigned char i;
#pragma zpsym("i")
extern unsigned char frame_cnt;
#pragma zpsym("frame_cnt")
-Thom
Re: WIP: Wizard of Wor
Enough refactoring was done that I was able to start work on shooting the lasers for the player.
The logic has become quite complex, ensuring that all possible states are being taken care of (there are still a few stray state leaks that I need to plug up), resulting in very dense blocks of ternary conditionals...I will try to document these once they've stabilized.
I am currently using yellow's score to track his states (player left idle, player left, player left shooting, player left shooting idle, etc.), as well as his previous state, and whether the shooting latch is active.
There are still a ton of bugs, and I am working through them, but for now:
-Thom
The logic has become quite complex, ensuring that all possible states are being taken care of (there are still a few stray state leaks that I need to plug up), resulting in very dense blocks of ternary conditionals...I will try to document these once they've stabilized.
I am currently using yellow's score to track his states (player left idle, player left, player left shooting, player left shooting idle, etc.), as well as his previous state, and whether the shooting latch is active.
There are still a ton of bugs, and I am working through them, but for now:
-Thom
Re: WIP: Wizard of Wor
First pass of player shooting implemented, now implementing monster shooting.
Latest binary here:
Latest binary here:
Re: WIP: Wizard of Wor
I've now implemented the first pass of monster shooting.
I initially tried to be somewhat smart about monster shooting; only shooting if the monster sees a worrior in its field of vision. This wound up taking up too many cycles, slowing down the entire game, even if all I was doing was checking for the same X or Y box through wall boundaries, especially since I didn't want them to shoot continuously....so the implementation I wound up using was far more naive:
I will definitely have to be careful with the blue worrior auto-move implementation (when playing 1 player), as it's clear that I am low on non-NMI cycles.
Latest ROM here:
I initially tried to be somewhat smart about monster shooting; only shooting if the monster sees a worrior in its field of vision. This wound up taking up too many cycles, slowing down the entire game, even if all I was doing was checking for the same X or Y box through wall boundaries, especially since I didn't want them to shoot continuously....so the implementation I wound up using was far more naive:
Code: Select all
void monster_shoot(void)
{
// This is holy shit naive. The previous naive implementation took too much CPU time.
if (rand8()>0xC0)
{
if (((rand8())<0x08) && lasers[LASER_SHOOTING(i)]==0 && monster_laser_count<4)
{
monster_laser_fire(i);
}
}
if (lasers[LASER_SHOOTING(i)]==1)
{
get_current_laser_box();
if (lasers[LASER_DIRECTION(i)]==STATE_MONSTER_RIGHT)
{
if (BOX_WALL_RIGHT(h) && lasers[LASER_X(i)]==PIXEL_BOX_X(e))
monster_laser_stop(i);
else
lasers[LASER_X(i)]+=4;
}
else if (lasers[LASER_DIRECTION(i)]==STATE_MONSTER_LEFT)
{
if (BOX_WALL_LEFT(h) && lasers[LASER_X(i)]==PIXEL_BOX_X(e))
monster_laser_stop(i);
else
lasers[LASER_X(i)]-=4;
}
else if (lasers[LASER_DIRECTION(i)]==STATE_MONSTER_DOWN)
{
if (BOX_WALL_DOWN(h) && lasers[LASER_Y(i)]==PIXEL_BOX_Y(f))
monster_laser_stop(i);
else
lasers[LASER_Y(i)]+=4;
}
else if (lasers[LASER_DIRECTION(i)]==STATE_MONSTER_UP)
{
if (BOX_WALL_UP(h) && lasers[LASER_Y(i)]==PIXEL_BOX_Y(f))
monster_laser_stop(i);
else
lasers[LASER_Y(i)]-=4;
}
}
}
Latest ROM here:
Re: WIP: Wizard of Wor
I'm curious about how you were losing so many cycles on just a bounds check ... maybe memory pointers ?
Re: WIP: Wizard of Wor
I will revisit that later. I'm guessing that sometime soon I will need to do some significant code optimization. If you want to see where things are @ this point, the code as always is in github: http://github.com/tschak909/wowlidnariq wrote:I'm curious about how you were losing so many cycles on just a bounds check ... maybe memory pointers ?
Now i'm deliberating on whether to implement blue worrior ai logic or to implement the kill logic first.
-Thom
Re: WIP: Wizard of Wor
Initial pass of Worrior AI logic implemented. However, I need to figure out why the blue worrior's laser isn't showing...
-Thom
-Thom
Re: WIP: Wizard of Wor
Ok, so first pass of blue AI is implemented. It's very naive at the moment, it simply picks a monster and starts walking toward it, shooting intermittently.
There was an odd situation where update_lasers() was short circuiting an over eager check to see if a laser should update, which was causing blue worrior's laser to not be visible. Fixed...
The random number seed is currently reset every 5 seconds and the player X position is used, to try and randomize player positions.
Currently, since no kill logic is implemented, once the blue worrior catches up to his enemy, he simply keeps chasing it, close behind, shooting intermittently.
Once kill logic is implemented, I will alter this to try and shoot any monster in path while traversing toward enemy...
There is also a very occasional intermittent slowdown when multiple lasers are visible from enemies...need to start optimizing soon.
And yes, I know, some sprite priority issues. I need to actually work on a sprite scheduler, as I don't think I have the bandwidth to put the phasors into vram updates.
Latest ROM attached: -Thom
There was an odd situation where update_lasers() was short circuiting an over eager check to see if a laser should update, which was causing blue worrior's laser to not be visible. Fixed...
The random number seed is currently reset every 5 seconds and the player X position is used, to try and randomize player positions.
Currently, since no kill logic is implemented, once the blue worrior catches up to his enemy, he simply keeps chasing it, close behind, shooting intermittently.
Once kill logic is implemented, I will alter this to try and shoot any monster in path while traversing toward enemy...
There is also a very occasional intermittent slowdown when multiple lasers are visible from enemies...need to start optimizing soon.
And yes, I know, some sprite priority issues. I need to actually work on a sprite scheduler, as I don't think I have the bandwidth to put the phasors into vram updates.
Latest ROM attached: -Thom
Re: WIP: Wizard of Wor
I've just drawn the explosion sprites. Am now implementing kill/explode logic:
I'm also fast running out of CHR ROM.
-Thom
I'm also fast running out of CHR ROM.
-Thom
Re: WIP: Wizard of Wor
Ok, major milestone, player to monster laser collisions implemented, along with explosions, monster death, and points.
Still some weird little sprite bugs that I need to track down there, as well. I'm having to tiptoe very well to make sure I don't run out of cycles doing e.g. bounding box comparisons, but it seems to be working ok, so far...
I'm happy this is starting to resemble a game.
Latest ROM build attached, and as always, code is available on github in the original post. Moving onward.
-Thom
Still some weird little sprite bugs that I need to track down there, as well. I'm having to tiptoe very well to make sure I don't run out of cycles doing e.g. bounding box comparisons, but it seems to be working ok, so far...
I'm happy this is starting to resemble a game.
Latest ROM build attached, and as always, code is available on github in the original post. Moving onward.
-Thom
Last edited by tschak909 on Wed Jan 31, 2018 7:08 am, edited 1 time in total.