IKD - Atari Combat remake

Use this forum to share and discuss Uzebox games and demos.
Post Reply
User avatar
danboid
Posts: 2097
Joined: Sun Jun 14, 2020 12:14 am

Re: IKD - Atari Combat remake

Post by danboid »

ArtcFox:

Thanks for the example you gave from your laser game. I should be able to re-use that to store the direction of bullets- one of 8 directions / every 45 degrees that gets reversed when it hits a wall
User avatar
danboid
Posts: 2097
Joined: Sun Jun 14, 2020 12:14 am

Re: IKD - Atari Combat remake

Post by danboid »

I think I know the easiest solution for bouncy bullets that I can realistically implement.

I'll have to rewrite processBullets() so that at every time the bullet crosses a grid/ maze division ie every 8 pixels horiz and vert it will check if:

The bullet has got higher than the top or lower than the bottom of the current grid location (in pixels). If there is a wall on that side of the grid, reverse the bullet velocity eg p1_bullet.vY *-1

and

If the bullet exits to the left or right of the current bullet grid location, inverse the horizontal velocity of the bullet (p1_bullet.vX) if there is a wall on the exiting side.

This may require keeping a record of the previous grid location of the bullets if we need to work out which direction the missile came from.
User avatar
D3thAdd3r
Posts: 3293
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: IKD - Atari Combat remake

Post by D3thAdd3r »

GPT kicks out relevant code answers, whoa...spooky.

That should be a valid for(), and ternary.

Not sure if the per pixel option was discissed in this thread(maybe I already did a while back?). I dont necessarily recommend it, but I think you can already figure out how to drive home the current idea, so heres another angle possible of similar complexity. I planned on this for a racing game stalled for years.

Depending on the graphics or your willingness to make 1bpp collision masks for everything, you can do pixel based collision with complex shapes. Basically iterate the movement of a projectile a very small amount until you reach the destination for that frame, or the direction changes due to collision. For each subtotal iteration, compare the 8x8 bitmap of the tile versus the overlapping parts of the sprite. Using small enough incremenets increases cycle use, but is a simple way to achieve arbitrary precision and potentially tiles that arent simple a single angle response without having to do clever math. You can also represent hard elements of any object(a higher rebound rate) and soft(not a purely elastic rebound) using different colors. You could even neglect the initial velocity and base the rebound entirely on the number and colors of the mask, where deeper overlaps automatically consider the constitution of the object for a realistic bounce.
User avatar
danboid
Posts: 2097
Joined: Sun Jun 14, 2020 12:14 am

Re: IKD - Atari Combat remake

Post by danboid »

Thanks for your suggestions D3thAdd4r!

I'm going to do it in the simplest way possible that I've been able to devise, as I summarised in this update to IKD's token feature request ticket I just wrote. I felt IKD deserved at least one GH ticket after almost three years working on it sporadically.

https://github.com/danboid/IKD/issues/1
Yesterday I added the menu option to toggle bouncy bullets so thats the easy bit done but it is still using the ping pong fake bouncy bullets code.

I had posted the above ChatGPT pseudocode before I had actually tried to read it properly. It looked promising skim reading it. When I came to try to implement / translate what it had suggested into real C code I realised the pseudocode was unusable even as pseudocode.

The code involved a direction variable that doesn't currently exist in IKD and it made reference to an unexplained function called level(), which I presume might supposedly operate like GetTile() but even if they were identical in use its suggestion still wouldn't work.

The only thing it got right really is that the new code for this needs to detect the bullet hitting walls and then reverse (* -1) either the bullets vX or vY values depeding on if the bullet is hitting the top, bottom, left or right boundary of the bullet's current tile, if a wall is present on that adjacent side of the tile.
User avatar
danboid
Posts: 2097
Joined: Sun Jun 14, 2020 12:14 am

Re: IKD - Atari Combat remake

Post by danboid »

I have commited my first attempt at 'proper' bouncy bullets for player one but its not quite working how I'd hoped yet. Player ones bullets bounce but in a rather unpredictable way.

EDIT

I improved it a little bit, enough for me to justify adding the same code to player 2. Flawed as it is, it works better than the ping-pong bullet code I was using for bouncy bullets before.
User avatar
danboid
Posts: 2097
Joined: Sun Jun 14, 2020 12:14 am

Re: IKD - Atari Combat remake

Post by danboid »

I described how my current bouncy bullet code kinda works to Jim Bagley and this was his reply:

"Don't worry typical noob mistake, basically you have to not move it at the speed it was going, you have see which squares it goes over. So, if the map of walls is on a tilemap you find the start tile, where it's last position was and then add one tile units worth of it's direction and speed and see which tiles it moved over until you have moved it's full distance. So if it's only changed tile in the Y, you check the tile above or below depending on direction each time it crosses.

Your process bullet routine would either have to loop until the length of the movement has drained and have the collisions inside or better still call a routine with current position and one unit vector which then checks tile crossover and returns it's continued direction ie if it needs to bounce and from what point. There's a bit of maths involved but it's the only way as when the bullet is currently very close but not touching a corner, next frame the new position would be diagonally across from it and thus register as ok to move when in fact it went through a block. That is your issue, very common when you're new to coding"
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: IKD - Atari Combat remake

Post by Artcfox »

danboid wrote: Sat Jan 14, 2023 12:09 pm I described how my current bouncy bullet code kinda works to Jim Bagley and this was his reply:

"Don't worry typical noob mistake, basically you have to not move it at the speed it was going, you have see which squares it goes over. So, if the map of walls is on a tilemap you find the start tile, where it's last position was and then add one tile units worth of it's direction and speed and see which tiles it moved over until you have moved it's full distance. So if it's only changed tile in the Y, you check the tile above or below depending on direction each time it crosses.

Your process bullet routine would either have to loop until the length of the movement has drained and have the collisions inside or better still call a routine with current position and one unit vector which then checks tile crossover and returns it's continued direction ie if it needs to bounce and from what point. There's a bit of maths involved but it's the only way as when the bullet is currently very close but not touching a corner, next frame the new position would be diagonally across from it and thus register as ok to move when in fact it went through a block. That is your issue, very common when you're new to coding"
Very nice! It sounds like you are figuring the right stuff out.
User avatar
danboid
Posts: 2097
Joined: Sun Jun 14, 2020 12:14 am

Re: IKD - Atari Combat remake

Post by danboid »

I'm still getting the hang of the basics.

A very nooby problem I came across today - is it not possible to print (char/string) variables using the Uzebox Print() function?

According to http://www.uzebox.org/wiki/index.php?ti ... tion_Print I can use a statement like:

Print(10,10, myStr);

but that only works with const chars ie non-variable "variables". Is there a way to work around this to get the print function to print a variable char string?
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: IKD - Atari Combat remake

Post by Artcfox »

Doing a

Code: Select all

git grep Print
in the

Code: Select all

~/uzebox/kernel
directory returns the following functions:

Code: Select all

uzebox.h:       extern void Print(int x,int y,const char *string);
uzebox.h:       extern void PrintRam(int x,int y,unsigned char *string);
uzebox.h:       extern void PrintBinaryByte(char x,char y,unsigned char byte);
uzebox.h:       extern void PrintHexByte(char x,char y,unsigned char byte);
uzebox.h:       extern void PrintHexInt(char x,char y,int byte);
uzebox.h:       extern void PrintHexLong(char x,char y, uint32_t value);
uzebox.h:       extern void PrintLong(int x,int y, unsigned long val);
uzebox.h:       extern void PrintByte(int x,int y, unsigned char val,bool zeropad);
uzebox.h:       extern void PrintChar(int x,int y,char c);
uzebox.h:       extern void PrintInt(int x,int y, unsigned int,bool zeropad);
It looks like you want to call

Code: Select all

PrintRam
instead. It will probably warn you that the type is unsigned char, which you should be able to safely ignore.
User avatar
danboid
Posts: 2097
Joined: Sun Jun 14, 2020 12:14 am

Re: IKD - Atari Combat remake

Post by danboid »

Thanks Artcfox!

PrintHexInt() was the best match for my needs. I've used that to add a secondary score display to count the tens. I wanted to keep the big chunky numerals as the main score count because I think it looks cool.
Post Reply