Zyx game collection #1

[+atari2600land]

Would anyone like to publish this game when I get it done?

[ggn]

You could ask @Gaztee and @omf if they're still doing physical releases. Otherwise AtariAge publishes Jaguar games as well.

[+atari2600land]

I am wondering something about the Zeroplayer. I've read the reference guide but there is something I don't understand. Is there a way to pause it, then resume it? What I'm doing now is inserting a bit of silence and have that play, but then when I want the music to resume it starts at the beginning instead of where it left off.

[Zerosquare]

1 hour ago, atari2600land said:

Is there a way to pause it, then resume it?

No, there's no way to do that with the current version.

[Clint Thompson]

Just have to think outside of the box or think adaptability-wise in regards to what you can do different to achieve similar results but in the end it doesn't sound like resuming a song from pause is really worthwhile if that's the intent or just leave the music playing. 

Edited September 4, 2020 by Clint Thompson

[+atari2600land]

I decided to keep the music playing during a paused game.

[omf]

what about switching to a very small looping silence ?  this will give the illusion of no sound

 

[+atari2600land]

I did that, but when I restarted the music, it started back at the beginning.

[WAVE 1 GAMES]

 

[WAVE 1 GAMES]

 

[WAVE 1 GAMES]

added powerups, a lava world and fleshed out a few more things with the gameplay

 

 

 

[WAVE 1 GAMES]

really? nothing? damn.

 

smh

[+CyranoJ]

1 minute ago, WAVE 1 GAMES said:

really? nothing? damn.

 

smh

Maybe we're all seen Fast food 3D graphics swap too many times already?

[WAVE 1 GAMES]

13 minutes ago, CyranoJ said:

Maybe we're all seen Fast food 3D graphics swap too many times already?

actually that comment wasn't for this thread, I had another AA window open and thought I was replying to a PM. I actually have 3 different AA tabs open in  firefox right now

 

and no this is not Fast Food. This a brand new project that I started from scratch using "build project new" in the command prompt for RB+

 

 

and I can prove it. See below file

 

 

3dzyx.bas

 

fastfood64.bas

 

but seriously I didn't mean to post that comment in this thread.

Edited December 27, 2020 by WAVE 1 GAMES

[+CyranoJ]

7 hours ago, WAVE 1 GAMES said:

and I can prove it. See below file

Does this really matter if it's a new .bas file if it looks like the exact same thing re-skinned again?

 

Animated image for a backdrop - check.

Sprites scaling in with no regard for z-order - check.

clipart - check.

short, looping sample in low quality - check.

[WAVE 1 GAMES]

2 hours ago, CyranoJ said:

Does this really matter if it's a new .bas file if it looks like the exact same thing re-skinned again?

 

Animated image for a backdrop - check.

Sprites scaling in with no regard for z-order - check.

clipart - check.

short, looping sample in low quality - check.

But the end result is not the same thing. Thats like saying mario and sonic are the same thing because both have sideways scrolling.

 

You clearly just see scaling objects and animation in the background and you just want to try and say its the same. It is not.

 

What clipart? I don't see any.

 

There is regard to z order here, although that does still need a little more work.

 

The music is not low quality, it sounds great. You cant just say something false and because you said it that makes it fact. (Ok Trump)

 

There is no on screen character in fast food

 

Fast Food is 1st person view with a crosshair and this is 3rd person view.

 

There is no jumping mechanic in fast food.

 

There is no kind of paralax in fast food

 

A loss happens when your character gets hit here, thats not the way it happens in fast food.

 

There are no powerups in fast food. Here there is which allows 2 different variations of play control.

 

The framerate and flow of play in fast food is choppy and slow. It is solid and fluid on both emulator and real hardware here.

 

This is actually pretty fun to play, Fast Food 64 VR mode not so much.

 

The code is different and the gameplay mechanics are not written in the same way. This is why I posted both .bas files above. They are not the same you can look at each file yourself. In fact anyone can look at those 2 code bases and tell they are different. That's proof.

 

I told you I didn't mean to even post that comment here, (I goofed) the comment wasn't even about this!

 

Stop giving me shit just for the sake of giving me shit already.

[Welshworrier]

After looking through your code I feel like it's possible I'm going to die in 7 days.

 

What is evident is:

1. You have absolutely no idea of code design and reuse. Is the reason for using two sprites for the banana because you forgot to scale hit boxes?

 

2. You cut and paste blocks of code that have the same function, then change the sprite name while also not understanding basic maths.  E.g. sprite scaling using a case statement that has a simple mathematical relationship between the values (hint: every increase of 3 adds 2). Also worth noting that you are using the 'timer' to simulate z depth.

 

3. Your movement/joystick routine is hard coded for all possible items on screen. It doesn't scale as a result.

 

4. Your music playback is meh because you don't understand the effect sample rates and playback have on audio quality (suggest a read up on Nyquist for why doubling sample rates and then playing back at half speed is a bad thing). E.g. https://blogs.surrey.ac.uk/arts/2015/07/08/a-painful-lesson-in-sampling-rates/

 

 

 

 

[WAVE 1 GAMES]

37 minutes ago, Welshworrier said:

After looking through your code I feel like it's possible I'm going to die in 7 days.

 

What is evident is:

1. You have absolutely no idea of code design and reuse. Is the reason for using two sprites for the banana because you forgot to scale hit boxes?

 

2. You cut and paste blocks of code that have the same function, then change the sprite name while also not understanding basic maths.  E.g. sprite scaling using a case statement that has a simple mathematical relationship between the values (hint: every increase of 3 adds 2). Also worth noting that you are using the 'timer' to simulate z depth.

 

3. Your movement/joystick routine is hard coded for all possible items on screen. It doesn't scale as a result.

 

4. Your music playback is meh because you don't understand the effect sample rates and playback have on audio quality (suggest a read up on Nyquist for why doubling sample rates and then playing back at half speed is a bad thing). E.g. https://blogs.surrey.ac.uk/arts/2015/07/08/a-painful-lesson-in-sampling-rates/

 

 

 

 

 

Why would reading code cause you to die in a week? You're just being silly.

 

1 yes I do. You dont understand how the game is working. There are 2 different sprites for the banana used because they are different images. What you speak of is the banana that flies away in the foreground zone which is more eluminated than the standard banana sprite thus requiring a different image. Also the point of impact for both the character and the bananas is always the same as the player never moves into the playfield or back into the foreground therefore there is no need to resize any hitboxes. The hitboxes here are standard per sprite half size vertical and horizontal from center of sprite.

 

2 yes I am using a counter to simulate depth on all objects. Yes this is done using a case statement. Im not sure what issue you are implying that this creates as it is providing the desired effect with no issues. I really don't know what you're getting at here. (Elaborate please)

 

3 what doesn't scale because of the movement? Everything that is supposed to scale does scale and the joystick movement doesn't have anything to do with scaling. When you say "doesn't scale" do you mean something other than sprite scaling? Whatever you mean, the control here feels pretty good and there shouldn't be any connection to sprite scaling and controls anyway.

 

4 I do understand that different sample rates sound better or worse. For this project the sample rates I have chosen for the sounds are fine and again just seems like nitpicking. The sounds aren't distorted and they sound clear. What's the issue?

 

After I put the finishing touches on this mini game I am going to upload a skunk friendly binary here.

 

Edited December 27, 2020 by WAVE 1 GAMES

[WAVE 1 GAMES]

3DZYX_SKUNK.rom

 

This ROM is for use with the SKUNKBOARD and Phoenix Project emulator only

 

It will not load data correctly on the Jaguar Game Drive

 

It will also not run correctly in Virtual Jaguar Emulator

[LinkoVitch]

Your answer to 3 proves Welshworriers point 1.

 

When code is said to not scale it means that the code is very rigid to a specific use case, if a small aspect of that case changes then the code has to be changed to accommodate that use case.  Writing such rigid code and trying to make it fit, results in a tangled and complicated mess which ends up generally being the cause for bugs and is notoriously difficult to maintain and debug.  Writing modular scalable code, you could re-use common logic for different purposes (say Menu input and gameplay input with a joypad), without having to modify loads of code or produce tangled spaghetti code.

 

IE you could have something that reads pad input and presents it in a standard format.  Then have an interchangeable handler function for each use case, which knows how to interpret the users key presses into actions.  The game then references the appropriate handler for the appropriate part of the game.  If you then decide to change how the gameplay inputs work, you only need to handle the GamePlayControllerHandler and don't make any changes to the InputCore or the UIControllerHandler.  Using a modular and scalable solution also allows you to handle multiple input types, using adaptors and different handlers as required.

 

 

[WAVE 1 GAMES]

13 minutes ago, LinkoVitch said:

Your answer to 3 proves Welshworriers point 1.

 

When code is said to not scale it means that the code is very rigid to a specific use case, if a small aspect of that case changes then the code has to be changed to accommodate that use case.  Writing such rigid code and trying to make it fit, results in a tangled and complicated mess which ends up generally being the cause for bugs and is notoriously difficult to maintain and debug.  Writing modular scalable code, you could re-use common logic for different purposes (say Menu input and gameplay input with a joypad), without having to modify loads of code or produce tangled spaghetti code.

 

IE you could have something that reads pad input and presents it in a standard format.  Then have an interchangeable handler function for each use case, which knows how to interpret the users key presses into actions.  The game then references the appropriate handler for the appropriate part of the game.  If you then decide to change how the gameplay inputs work, you only need to handle the GamePlayControllerHandler and don't make any changes to the InputCore or the UIControllerHandler.  Using a modular and scalable solution also allows you to handle multiple input types, using adaptors and different handlers as required.

 

 

I don't understand.

I don't have any code set to not scale.

I don't know what either of you are talking about.

I have never heard of scaling code, I assumed he meant sprite scaling.

As for the pad input, it's functioning perfectly so I'm not understanding why it seems like you guys want me to reinvent the wheel in that regard.

Everything I've done here in this mini game is working fine and as intended. I'm all for a better way to do things and why not learn something new with something as simple as this, but you guys are confusing me with what you're saying and the way you are explaining it.

Are you both saying I'm using case select function wrong? Why is the way that I'm using case select wrong if it provides the desired effect?

[Welshworrier]

Because it's incredibly inefficient/slower

 

Here is a simple example, if you do a select statement which has 20 plus discrete values - but 15 of them are the same operation with a slightly different value then the code you would be generating would have to do upto 20 comparisons before executing the bit you wanted.

 

So, in your scaling code for example, by the time you got to the value 23  you will have already had to test if it is 20,17,14 etc. All these operations carry out the same scaling function but have an addition you could already have obtained from the passed number.

Compare this with the following:

 if X is greater than 13 and less than 70 

   Scale Xpos by (X-13)*2/3+4

   Scale ypos by (x-13)*2/3+4

Endif 

Only has to do 2 compares and a computation for all values in the range.

This compares with the between 2 and 20 for every entry in your version. It also doesn't slow down execution as the number gets higher.

 

Scaling is as LinkoVich said - you have no design for the code, a simple change in one area will have knock on effects throughout the entire code.

 

As for the sound I take it you applied suitable filters to the audio to account for the aliasing effects you'll encounter playing it back at a different rate.

 

 

 

 

 

 

[WAVE 1 GAMES]

3 minutes ago, Welshworrier said:

Because it's incredibly inefficient/slower

 

Here is a simple example, if you do a select statement which has 20 plus discrete values - but 15 of them are the same operation with a slightly different value then the code you would be generating would have to do upto 20 comparisons before executing the bit you wanted.

 

So, in your scaling code for example, by the time you got to the value 23  you will have already had to test if it is 20,17,14 etc. All these operations carry out the same scaling function but have an addition you could already have obtained from the passed number.

Compare this with the following:

 if X is greater than 13 and less than 70 

   Scale Xpos by (X-13)*2/3+4

   Scale ypos by (x-13)*2/3+4

Endif 

Only has to do 2 compares and a computation for all values in the range.

This compares with the between 2 and 20 for every entry in your version. It also doesn't slow down execution as the number gets higher.

 

Scaling is as LinkoVich said - you have no design for the code, a simple change in one area will have knock on effects throughout the entire code.

 

As for the sound I take it you applied suitable filters to the audio to account for the aliasing effects you'll encounter playing it back at a different rate.

 

 

 

 

 

 

So you are saying in a single IF instance like the example you provided it saves processing time and in the way I am doing the case selects it has to read from the entire list up until the point of action we want change X to take place?

 

The reason I'm asking this question is I thought that it only checks the case value once before it even attempts to go through the list. So the way I understood it was if the case number was lets say 15 it would cut straight to whatever events you have associated with case 15 and never mind any  of the cases prior to 15? with the example you gave it is also checking 2 values and with the way I have been doing it if I wanted to do that, an individual if statement would be within that case to check for the second value.

 

so if we are checking 2 values like your example which is really just determining a number between 13-70, it would be better and faster to use an individual IF statement vs including that in a case select list? Or are case select lists just slower all the way around in general because it digs through the entire list of possible variables?

 

"Scaling is as LinkoVich said - you have no design for the code, a simple change in one area will have knock on effects throughout the entire code"

 

I guess that does hold true in regard to the way things are currently written if I change one thing it does in fact do that.

[LinkoVitch]

Google is your friend.  Simple google of "writing scalable code" gives a bunch of results.  We are not making these terms up!  1st link: https://blog.sarasarya.com/what-the-hell-is-scalable-code-anyway-f6626ad78227

 

Scalability applies to more than just sprites.

 

RE Switch.. Think about it, how does the computer know what part of the case statement to run?  It doesn't magically know that a value of 15 = run this code.. it has to check each possible solution to figure out what bit of code to run.  So a Switch statement with 100 possible cases will compare the input value with each in turn until it finds the one that matches and then run that.. So if you have 100 cases and the value you pass in doesn't match any of them, it will check against all 100 and then move on to the next instruction after the switch, so you just made 100 comparisons for nothing!

 

From a cursory glance at your code I assume you are using a counter to indicate when something should happen? when it reaches a certain value, do a thing and you are using the switch statement to decide what thing to do, but you are doing this every iteration, so even at times when nothing should happen.  I am sure there will be more efficient ways to trigger "events" and the like at set times, some things may happen on a timer, but I doubt everything should do.  This is the designing part of the code, figure out how to do as little as possible each frame/tick/iteration, only trigger events when it makes sense, if something can only happen after a specific other event has happened, don't test for it every iteration, only after that event, or trigger it directly from that event.

 

Programming isn't a simple subject there are many many many ways to do a thing (especially in games!) which is why it's so much fun, there is so much to learn and expand on, I've been coding for probably 30 years, I am still learning new things.

 

[LinkoVitch]

21 minutes ago, WAVE 1 GAMES said:

I guess that does hold true in regard to the way things are currently written if I change one thing it does in fact do that.

 

unless you decide you want to insert something part way through or at the start of one of your switch statements.. at the moment you will have to update the values for all the subsequent case statements with new values.  As that Switch statement grows, the amount of effort to make a small change near the start becomes more complex and time consuming, making it more faff to tinker and change things later.