Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

WAVE 1 GAMES

Members
 View Profile  See their activity

  • Content Count

    1,586

  • Joined

  • Last visited

Posts posted by WAVE 1 GAMES

  1. Posted

    2 minutes ago, CyranoJ said:

    And this is why the collisions in *ALL* your games are wrong.

    The hitbox sizes do *NOT* scale with the sprite scale size.  Again, it's a failure to understand something rudementary on your part.  Stop projecting and writing essays that just dig the hole deeper.

    I already know that.

  2. Posted

    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.

  3. Posted

    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?

  5. Posted · Edited by 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.

     

  6. Posted

    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.

  7. Posted · Edited by 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.

  11. Posted

    2 hours ago, ggn said:

    Ok, since I replied to a private e-mail the other day and I've been getting some PMs, I might as well post here:

     

    Just do whatever you wish to do with the project. Fork it, rename it, rip out bits of it and use it elsewhere, redo from scratch - it's all good! It's not like I'll lose millions on it or something. Just use your common sense and it'll all be fine. And for people that like FAQs, here is the same thing in that format:

     

    Q: Can I....? (assuming using common sense)

    A: Yes!

     

    So, Merry Christmas to everyone and stay safe! (and have fun with this)

    Merry Christmas ggn!

  14. Posted

    2 hours ago, CyranoJ said:

    OK, lets fix this once and for all...

    The problem here is that no matter what you do, the original RAPTOR.O file sets it back (because I stupidly left code in there for the Jagtopus board)

     

    Hex search the original raptor.o file for:

    $33c0 00f0 0000

     

    replace it with

     

    $4e71 4e71 4e71

     

    Remove *any* and *all* references to MEMCON1 in any part of your projects (do a 'find in files') - rebuild... and.. should be working.

     

     

    Is this the correct address in RAPTOR.O you are referring to?

     

    raptor.thumb.PNG.1f7fee7f185ec46a39e91540c4397539.PNG

     

     

     

  16. Posted

    Would anyone like to lend a hand at providing a voice sample for JagZombies 2? I need a dark creepy voice similar to the voice that says "RELOAD" in the video to say "AREA CLEAR" for the end of each stage. I have tried to replicate this sound using various text to speech programs but none quite come close to what I'm looking for

  17. Posted

    1 hour ago, 7800JAGFAN said:

    Well we are getting way ahead of ourselves here, but- if you did a fighting game, consider a Beat-em-up instead.   Maybe picture "Final Fight" occuring during a "Zombie Apocaplypse".  I think it would be much more fun, and fit "JagZombies" theme much better.   Just a thought. 

    That's a very good idea. That actually could work with the story elements I have set up as well. I will definitely keep that idea at the top of the list. Perhaps that could be the main game and the shooting and 1 on 1 combat could be secondary modes.

     

    But I agree, it's far too early to make any kind of permanent decisions at this point. Right now JagZombies 2 is being finalised and that is priority 1.

  19. Posted

    47 minutes ago, gummy said:

    This sounds very promising. However, I am slightly concerned that you might be biting off more than you can chew, so to say.  Don't get me wrong, your releases up to this point have definitely shown promise but this us a huge step forward in complexity. 

     

    I guess it would be easiest to mold my concerns into a question for you, how have you grown as a developer to take on a project of this caliber? And as a 2nd question are there any specific potential pitfalls you see with this project based on your past experiences. 

     

    how have you grown as a developer to take on a project of this caliber?

     

     

     

    Wow. First of all JagZombies 3 is only a concept drawn up on paper at this point. It hasn't been started on, but to clear the air let me elaborate.

     

    1. I wouldn't be going it alone on the fighting game portion of the code. There is another AA member who I will leave anonymous at this time who has experience making a proven fighting game engine on the Jaguar. I have been working with him behind the scenes at trying to do some sort of fighting game on the Jaguar but up until this point haven't came up with a solid concept. This project would be the fruit of that collaboration. He has already told me that he is willing to assist in that regard so I would have reliable help.

     

    2. As for my ability to "get the job done" Let's look at just how "complex" the fighting portion needs to be. (I'll touch on the shooting portions later on) If you have 10 characters in a fighting game let's say each character has 6 moves (just an example) that's 60 individual animations for moves. Each animation can be stored as a ROM asset and then pulled into RAM when needed to be viewed or from the players' perspective; when he or she executed their move properly. Once the animation has played it can then be kicked from RAM and be brought back again when needed. JagZombies 3 would likely need to be a 6MB game in order to hold that many animations. But pulling the necessary animations from ROM for each character in order to keep a vibrant highly animated game is well within my capabilities. I am already doing the same exact thing here in JagZombies 2. Of course collisions would also be a key factor in a proper fighting game so each character would likely need to have multiple hit boxes in order for the fighting to be fighting to be convincing and accurate. Where is my experience in that? Each zombie in JagZombies 2 actually has multiple hit boxes (I just haven't revealed that yet) The main hitbox is for the body and the secondary hit box for each character is for the head, enabling a head shot triggered animation when fired on. (again you just haven't seen it yet) So this process would then be adapted to serve as hit boxes for things such as limbs in a fighting scenario. Scrolling and animated parallax backgrounds would also be expected and as I have already proven in my many JagZombies 2 updates I seem to have the hang of that.  

     

    3. I worked for years with M.U.G.E.N. and fully understand how a fighting game is made and how it should play. I was the original creator of the M.U.G.E.N. character Falco (from SMB) and somebody else took my character file and updated it and claimed it as their own. (but who really cares? it really belongs to Nintendo)

     

    4. As far as biting off more than I can chew and the scale of the project, that is merely a matter of perspective. In my opinion every single Jaguar game is a huge project. There is no "easy peasy" regardless of what others have stated, so why not try and do something different and better? I am not scared of a challenge, hell it could be challenging to try and replicate something as simple as 2600 Battlezone on the Jaguar, this is something you wouldn't actually know until you sat down and really tried it. Sure you can speculate and say "no way man, that can't be hard" but you really wouldn't know until you got your hands on it and actually tried. (I don't actually think it would be, I'm just using Battlezone as an example. Stick any other seemingly simple concept of a game into this sentence)

     

     

    5. You must remember that this idea is not Mortal Kombat, It is not Street Fighter, It is not Killer Instinct, and it is not King Of Fighters. It is JagZombies. Therefore it can't and won't be held up to the same expectations as those games. It won't follow the same rules and it won't play the same way. What do I mean by that? Am I just making an excuse to make the gameplay subpar? Not at all. Super Smash Bros is an example of a fighting game and it is not like those games in it's style or mechanics. it has its own flavor, it's own rules and it does not follow the standard set in stone by the others I mentioned. A JagZombies fighting game would most definitely do things differently in that regard. How much sense would it make for a zombie fighting game to have fatalities if both fighters are already dead? There would have to be an entirely different mechanic here and that is just one of the examples. To my knowledge there has never been a zombie fighting game before so in the end whatever rules and mechanics I come up with could very well become the standard setter should anyone else try this concept in the future. 

     

    6. The shooting mode of the game. Well I think I've done enough shooting games now to be able to pull that part off. a 3/4 top view isometric perspective is simply that. A viewpoint perspective. I don't even expect making that portion of the game to be a mild challenge. So I'm not really sure why that would seem like a daunting task for me to accomplish.

     

    are there any specific potential pitfalls you see with this project based on your past experiences. 

     

    sure I already see one potential pitfall based on past experiences. Don't over share while in the development stages, just get it done and then share

  20. Posted

    11 minutes ago, Sporadic said:

    I don't get the obsession people have with Jaguar games having to look a particular way with as many colours and detail as possible.  Just because the hardware can do something, doesn't mean the developer has to.

     

    This this case, he might have been intentionally going for that art style as it suits the genre.

     

    I'm sure most of us have games on our PCs and mobiles that don't take advantage of the hardware. In many cases, it's because the developer or designer wanted it that way.

     

     

    fair point.

     

    I was merely making a suggestion. It is of course his game and he can do whatever he wants.

  21. Posted · Edited by WAVE 1 GAMES

    6 hours ago, agradeneu said:

    These tiles look isometric and thus this won't fit his engine? Also , he probably needs something like 16x16 tiles.

    I'm not specifically talking about the tiles. I am specifically talking about the trees.

     

    343991533_phoboztree.PNG.dcdb8dae8ec88d194986ea7543d3b92d.PNG   1661955096_reinertree.PNG.8929f1fab2d4ad3e731c3226e7f94d0e.PNG

     

    His trees are also at the same isometric angle. There wouldn't need to be any change to his engine in order to use them. In regard to the tiles, there are flat squares of grass here too that could be adapted and used as well. The characters and creatures may need to be looked at a little more, but he could still pull it off and have a much more impressive looking game in terms of visual style than what's been presented here in the proof of concept video.

     

    as far as needing 16X16 they can always be resized or scaled down.

     

    In any case I'm sure the game will turn out great and people will love it. It's nice to see phoboz filling the RPG gap on the Jaguar, I'm merely suggesting he raise the bar in the visuals if there is no rush on releasing the game, because why not?

     

    If you were the one who designed his sprites and tiles I am not trashing your artwork. These graphics DO look nice and well made. But they look nice for a GAMEBOY ADVANCE game, a Sega GENESIS game or a SNES game, not a game on the Atari Jaguar.

     

    So this doesn't mean the sprites and tiles presented here are bad at all, it just means that I (among others I've read elsewhere) would like to see something more realistic in regards to visuals for an RPG on the Jaguar.

     

    I look forward to seeing how the gameplay turns out regardless of the graphics style. I think with enough time and work put in this game could really be something Jaguar owners have been longing for all of these years.

  22. Posted · Edited by WAVE 1 GAMES

    To be honest the graphics look a bit like NES graphics. These visuals leave much to be desired. Even with randomized levels you can probably pull off much better looking sprites on the Jag. If there is no rush to release this one, I would recommend you hire a pixel artist. Or check out some of the great graphics provided for free use online.
     
    For this game you should really check out Reiner's Tilesets. The sprites here are of much better quality and fit your theme.
     
     
    check out the 2D graphics tab and environments, animals, creatures and humans. There is a lot there and as I already stated these graphics fall in line with your theme

  23. Posted · Edited by WAVE 1 GAMES

    19 minutes ago, RetrousJag64 said:

    ...Maybe an idea for Jagzombies 3: Console of the Dead. 😉 

    Actually... Its going to be called JagZombies 3: Necro Brawl. The plan is to make an entirely different type of game. It's going to be a 2D fighting game in the style of Mortal Kombat with shooting game elements. You will select your zombie and fight head to head against a ladder of 10 other zombies until you reach the Batlord. The game will also contain a "shooting mode" similar to the first 2 games in spirit but work a bit differently. The shooting mode will be 3/4 top view (think cannon fodder or Syndicate) and you will help guide civilians to a safe point in each area  by shooting a path through incoming zombies. The reason why the plans for this game are already drawn up is because there are events that are going to take place in the final level of JagZombies 2 (the Cathedral stage) that lead up to this. I put myself in the mind of the generic zombies getting shot and realized these were just normal people who never asked to be zombies and I think that angle can be played out nicely.

     

    So although I do appreciate your brainstorming of ideas and I will take notes on them, a very different sequel has already been drawn up.

  24. Posted

    1 hour ago, tbs123456 said:

    Looks good. I would agree with slowing down the hallway affect as the scrolling goes by to quickly compared to the creatures. Makes it look more like a projected background running on a loop than part of the actual game. Maybe half the speed? I like the face hugging spiders. Does the screen flash red when they have you, or was that the zombie attacking?

    The screen flashes red both when the zombies hit you and while the "facehugger" spiders are on the screen

     

     

  25. Posted · Edited by WAVE 1 GAMES

    7 minutes ago, Machine said:

    Sorry, I thought it was a roach crawling the first time I saw it. Then I notice the ammo on the bottom and I realized it was an empty shell.....my bad.

    Well in any case you caught something I missed because that was NOT on my list. I was too focused on the creatures I never even noticed that wasn't doing what it was supposed to be doing. I should be able to fix that too, its just supposed to be a simple effect of each shell flying off screen but obviously we have an issue here when you rapid fire they are wigging out.

    I never noticed because I was focused on what I was rapid firing at (the spiders) so never even looked down there. I appreciate you catching that.

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...