Problem with sprites & arrays

SteveZX81

I honestly appreciate the help, thank you so very much. ( I sadly cannot grasp the concept but that does not matter)
Thanks!

Tratax

Hey @SteveZX81 - Can you share a screenshot of what the game looks like so far? It sounds like the coins will be hit at the bottom row?

SteveZX81

Screenshot, sure!

Nisse5

@SteveZX81 said in Problem with sprites & arrays:

I honestly appreciate the help, thank you so very much. ( I sadly cannot grasp the concept but that does not matter)
Thanks!

First, according to the screen shot it seems like you have mixed "col" and "row" in the source code. (You have 5 rows with yellow coins, not 19.)

If you set the x-position of the sprite with "xpixelpos=500+col*48" (based on your source code for yellow coins), you do the reverse to get the column number from a sprite position: "col=(xpixelpos-500)/48"

Tratax

@SteveZX81 So I tend to think of grid based games in two frames of mind:

the "logical layer", mapping out each tile,object,etc as a position on a blank grid, where each positition from x,y represents a trackable and variable location (grid paper and excel is great for this)
the graphical representation of what may happen "above" that layer where all the creative stuff happens

For your game, assuming we had 6 columns and 10 rows: I would first have a function or routine that determines where the logical layer change will occur for where the collision takes place. With that determined we then have a known position for the collisions X/Y (say the bomb falls 6 positions down) and can perform a for loop checking if state had changed then update the top value in that column from say 2, to 0.
On the graphical layer as part of your draw routine, you can then associate your drawn sprite against the new grid value

Does that help?

SteveZX81

uhm.. okay, well thank you!

Richard

It would have been easier to store the coins in a 2 dimensional array, but since you've used a single dimension the coin above coin[i] is coin[i-width] where width is how many coins are in each row of your display, which is 19 in the case of your yellow coins. So for example if you have a collision on coin[40] the one above it would be coin[21] and the one above that would be coin[2]. Also I agree with @Nisse5 that you've got the columns and rows swapped.

SteveZX81

Thanks, you know I must have a blind spot when it comes to rows and columns, I've always thought that columns were vertical and rows horizontal. oops!

Dave

Hi Steve

Awesome project idea and so far it's looking great. I will be using this idea for a video at some point down the line, as this technique is so transferable to other game ideas!

It looks to me like you'd benefit from a slightly cleaner laid out Coins array, using a structure:

rows = 5
cols = 19
array coins[rows][cols] = [
    .spr = createSprite(),
    .pos = {},
    .active = true,
    .falling = false,
    .hit = false
]

// You'll still have to do a loop to set sprite image etc
for r = 0 to rows loop
    for c = 0 to cols loop
        setSpriteImage( coins[r][c].spr, coinImg )
    repeat
repeat

With this setup, you have different states a coin can be in, and it's tracked more easily than having multiple arrays for different states. If you want to check a coin:

for r = 0 to rows loop
    for c = 0 to cols loop
        if !coin[r][c].active then
            setSpriteVisibility( coins[r][c].spr, false )
        endif
        if !coin[r + 1][c].active then
            coin[r][c].falling = true
        endif
        if coins[r][c].falling then
             // Make your coin fall
        endif
    repeat
repeat

Just in case it's not clear, I've written "if !coin[r][c].active". This is exactly the same as "if coin[r][c].active == false".

Apologies that this isn't exactly a solution to your problem yet - I'll be taking a look today in more detail. Will get back to you Steve!

However, in the meantime you might have more success in experimenting with a setup similar to that above.

Thank you to everyone helping in the thread! Also @SteveZX81, I was exactly the same with Rows and Columns... It really doesn't matter which way around you do it as long as you're consistent, but conventionally yes, row is vertical position and column is horizontal position. Rows of columns.

It took @Luke repeatedly shouting "ROWS OF COLUMNS!" at me before it sunk in haha.

Martin

@SteveZX81 said in Problem with sprites & arrays:

Thanks, you know I must have a blind spot when it comes to rows and columns, I've always thought that columns were vertical and rows horizontal. oops!

Err, they are! In the real world at least.

SteveZX81

Thanks Dave! The reason I didn't use structures is that quite frankly I don't feel I understand them enough to use them, but I'll use your code above as a good learning opportunity and see if I can get this working. (edit: jeez this is hard. eek!)

Thank you!

Richard

@Martin Agreed, but in the code you're not trying to define what a row is, but indicate which row you are on.

SteveZX81

Just want to say thanks to everyone who's tried to help. I really appreciate your help and your time but I've decided to wave the white flag on this and give up, so no point in any more replies but again thank you!

pianofire

@SteveZX81 That is a shame but I understand it can be frustrating. Maybe come back to it later.

Jonboy

Steve, no matter what, it's very important to spend some time on structures as they are very powerful and once grasped really easy. Secondly, and this is just my opinion, coding using states is really, really important. States are not part of the language, they are just a concept.

I've almost finished my arcade remake of Rescue from Stern. It has taught me so much about using states that i wish i'd done it ten years ago!

Every single variation of an items existence is simply a state. In the case of Rescue i have a little bloke falling from the sky:

soldier.parachuting = 0
soldier.falling = 1
soldier.swimming = 2
soldier.sinking = 3

if soldier.state == soldier.parachuting then
run this bit of code
endif

If soldier.state = soldier.falling
run this bit of code
endif

If soldier.state = soldier.swimming
run this bit of code
endif

soldier.state = soldier.sinking
run this bit of code
endif

If I have ten different items existing the process is the same for all of them. This way it is easy to have everything happening at once all with their own little controls.

Generally each state, once it has been set moves on to the next state. So when my soldier has successfully parachuted into the water he changes to .swimming but if he got hit on the way then he goes into .falling and when he hits the water, well he’s dead by now so he’s .sinking – poor little thing!

I was really worried when I saw your ‘white flag’ post. Just a couple of days ago I sent a comment to the team listing games I’d love to see and Atari’s Canyon Bomber (1977) was in the list so I was really chuffed to see you had taken it on. Canyon Bomber was one of the first true video games I played in the grand old holiday town of Minehead in Somerset.

If I can be of any assistance with the project then let me know. My email is jon.silvera@fuze.co.uk and I’d be very happy to help if I can.

I think it should be in Black and White though!

Martin

@SteveZX81 - ignore this, I don't want to confuse you!
@Jonboy - quick tip, and sorry if you already know this.

if instead of

soldier.parachuting = 0
soldier.falling = 1
soldier.swimming = 2
soldier.sinking = 3

You have

soldier.parachuting = 1
soldier.falling = 2
soldier.swimming = 4
soldier.sinking = 8

Then it becomes possible to do bitwise logic on your state. It may not seem like much and is actually totally irrelevant to your use case because your soldier can't be doing two things at once, but let's say that your soldier could be both swimming and sinking at the same time (maybe he can't swim very well!) Then soldier.state would be 12. In the code you would say:

soldier.state = soldier.swimming | soldier.sinking

And when you know that it is possible for your soldier to do two things at once, ask if he is swimming by saying:

if soldier.state & soldier.swimming then

We don't care what else they may be doing, but we know they are at least swimming!

Like I say, bordering on shouldn't be in the beginning help section, and no good for your use case, but I just wanted to mention it since it ties in with the state stuff you mentioned.

sys64738

@Martin this is exactly how wavetables work in the c64 sid chip so you can use 2 waveforms in single note. well not using logic, but bits in fuze 0000 0000 is square 0000 0100 is noise so 0000 0101 would be square and noise together (feel free to make fuze capable of this)

Thanks for the posts about states, I had been doing a ghetto version of this to tell what my octopus in the deep is up to, I might convert him to a struct since as a learning process.

Games looking good steve, just come back to it when you are ready, Maybe start another project for now. I have same problem with my the deep project, trying to learn too many new concepts is overwhelming, I do my best coding in the shower (when I'm away from it all) haha

SteveZX81

I swear this software is turning me into a raving madman. I woke up at 4:32am this morning with an idea that I thought would solve my problem, so climbed out of bed in the middle of the night and tried it. of course it failed as per usual but still.. I must be insane. lol

pianofire

@SteveZX81 Ah yes 4AM programming. I know it well

MikeDX

Yep! sounds perfectly normal to me. wake up with idea and must try it. programming isn't typing, it's thinking. well actually the typing is the programming but the developer part is the thinking