WAVE 1 GAMES

You're not even reading what I'm writing. I said that the hit boxes here are configured here as half of the sprite size from the center. I said I am not manually adjusting the hitboxes as the sprites scale because it isn't necessary for the objects here as all collisions take place at the same point here ie the character never actually moves inward or outward of the playfield I never implied that the hitboxes automatically adjust when you're scaling a sprite size. You're taking what I'm writing out of context and accusing me of projecting so I'll spell it out more clearly; At no point did I make the claim that when you scale a sprite the hitboxes also scale. In order to do that you must set the hitboxes manually. (in some cases you may need to use an offset) What I did say was that hitboxes would not need to be scaled with the sprites here as that is not the way collisions take place on the character

I already know that.

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.

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?

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

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.

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.

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.

really? nothing? damn. smh

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

Merry Christmas ggn!

followed updated instructions and all is working as it should now. thank you

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

Got mine the other day. Quality seems great and excellent solder work on display here. Good job! Haven't started using it yet, I will be putting it to good use tonight.

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

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.

I am interested in one

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

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

I'm not specifically talking about the tiles. I am specifically talking about the trees. 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.

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. https://www.reinerstilesets.de/ 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