Jump to content

WAVE 1 GAMES

Members
  • Content Count

    1,438
  • Joined

  • Last visited

Community Reputation

703 Excellent

About WAVE 1 GAMES

  • Rank
    Stargunner
  • Birthday 03/07/1983

Profile Information

  • Gender
    Male
  • Location
    Charlotte, NC
  • Interests
    Game design.
    Currently working on:

    JagZombies 2: UNHOLY NIGHT and Jaguar Meets Space Invaders

    Finished Projects:
    SAUCER WARS (Atari Jaguar)
    Fast Food 64: Holiday Snacks (Atari Jaguar)
    ANTS (Atari Jaguar)
    JagZombies (Atari Jaguar)
    Fast Food 64 PC Edition (PC)
    A Frogz 64 Christmas Special Edition Release (Jaguar CD)
    Frogz 64 (Atari Jaguar)
    Fast Food 64 (Atari Jaguar)
    RETROPIA (PC)
    Diddy's Kong Quest 3D: Episode 1 (PC)
  • Currently Playing
    You
  • Playing Next
    1 player Combat on the Atari 2600

Recent Profile Visitors

11,867 profile views
  1. Well it will work with the Dpad on the second controller right out of the box. Would probably be an awkward play for most folks though considering how big the Jagpad is. So for Jag pads it would probably just be best to grab a buddy to help you shoot. I was trying to make something more intuitive for the 1 player experience should he choose to use dual shotgun mode. Hell even if I don't produce a twin stick for shooting the door will be wide open for Somebody else to come along later down the road and do it. That's just an extra anyway. Right now my main focus is getting this game done and making sure it exceeds all possible expectations.
  2. Actually what I had in mind was a dual stick arcade controller like the one for the sega saturn version of Virtual On Cyber Troopers. This would work fantastic for the games new dual shotgun mode which will put 2 crosshairs on screen at the same time via the player 2 port. I'm working with a few people to get this done at the moment but I'm not sure if it will end up being a reality or not.
  3. Flip flopping between Fishin' Frenzy and this these days. Not a whole lot has been done yet so not much to see yet but it's coming along. Already better than it's interior predecessor. No collision/hit detection work has been done as of the posting of this video. All hitboxes are placeholders for the moment. Mostly just been working on environments and the tone of the game so far. There will be animated head shots and fine tuned collisions this time around. Will be cart only and possibly Jaguar GD version. That's all the info I have for now.
  4. No not everything I currently have packed needs to be packed. Some of that stuff can live just fine as raw data. Im going to try reorganizing what gets packed and what doesn't. I actually DO want to try packing to rom and then unpacking. This was actually something I wanted to ask about but was afraid it was a stupid question. I'm familiar with how setting up the buffers as DIM objects work as I am already currently doing that for my packed stuff. So it will be a matter of figuring out how to align it properly to call from ROM in my case. Setting up a dummy object sounds like a good idea! As for the grassy ranch house background layer, that thing doesn't even need to be packed or even set to ROM. It can remain as ABS and it will work just fine. The hallway animation on the other hand will need to be in ROM. I'm not sure how I'm going to achieve this the way it's currently set up. It would be great if I could nix the scaling and use a full sized image as I know scaling takes a pretty big performance hit. I did try converting the frams to 4 bit color just to see how they would look but it looked terrible to me. This animation is semetrical so another thing I thought about was cutting it in half horizontally and then creating 2 background objects woth one being flipped. However I also realize sprite_flipped takes a performance hit as well. Anyway I am going to attempt to do this one way or another and I know I need to move some other stuff around to make this all work. If I have questions about packing to ROM I'll ask but I'm going to try and figure it out myself. Oh but I did have 2 other questions. 1) why is it that it will only allow me to designate 7 sound files as ROM? 2) Whats the limit on packed graphics, is there a limit as far as how many k/mb you pack or is it determined by the amount of images you pack? ie number of slots/bmps files packed? Thanks for the help.
  5. ok so just did a quick playthrough to get to the other stage that is using a bmp from ROM. the bmp file in question is this one: ranch.bmp its not very hefty at all in size and displays just fine when I load from load from ABS. the layer in question is the grassy one with the ranch house on it. it is also a 16 bit color image. it should look like this in game: however if you go to the 1:09 mark of this video you can see this is distorted as well: Now with this particular bmp file only being 83k and me knowing full well if I change it to ABS in the assets file it will display perfectly, I'm not inclined to believe (at least not in this particular case) that I am over running the OP here. If you look at the distortion in this video we have sound glitching as well as lines and the image appears to be scaled up! There is no scaling on this particular object so that's a bit strange, I'm wondering if this is due to the SKUNK's bus or if it's just a matter of doing it a different way. Maybe because I am playing a sound from ROM during this level AND trying to pull the bmp from ROM also in this instance? I simply don't know, but would love some input and in best case scenario find a "have my cake and eat it too" work around. I already know for the animated hallway sequence I COULD try going to 4 bit color mode on that, but that would mean I would have to make the background animation 1 large 4 bit bmp containing all 6 frames and of course it wouldn't look as nice. EDIT----> I did go back in and remove the music being played in the hallway sequence to see if it was an issue where I am fighting for both sound and graphics from ROM but there didn't appear to be any change there either
  6. ok so I recorded a video of it running on skunk with my celphone. The music files seem to be working flawlessly but the high resolution background animation for the hallway not so much. we don't get the large grey bars running through the image this time, but the game is hemorrhaging in terms of FPS and the image is distorted as well as everything else on screen at this time. I'm willing to bet I have have overloaded the OP, BUT I can test this too as I have another bmp that isn't as large that is also being pulled from ROM directly. I'll check that out next. In the meantime the dimensions for the graphics being distorted are 352X112. We are pointing to each graphic at the corresponding time in the counter sequence. They are 6 separate frames. they are 16 bit images. The image is being stretched X 64 vertically but no scaling horizontally. would love to come up with a workaround on this that doesn't involve sacrificing resolution or color depth, but now I am left wondering if this is due to the SKUNK bus speed or overloading the OP entirely. For reference I did try both the code from ggn and the code from zerosquare for this. ggn's code is the one that seems to be correctly pulling the assets from rom. the code from zerosquare delivers the same exact results as before.
  7. OH SNAAAAAAP I GOT IT WORKING it goes here in place of the other memcon command
  8. ok, so neither code snippet seems to have any effect when loading to skunk. I did put each one right after *YOUR APPLICATION GOES HERE MODIFY AWAY* Is there somewhere else that I can try putting the code, or does something else in the rapap.s file need to be changed in order for this code to take effect properly? I ask because I get the same exact results as before. First on audio and then on the bmp. It's as if we aren't doing anything differently at all. what about the universal boot header? doesn't RB+ use that when compiling a rom? does that need to be edited for proper width? I'm now going to try splitting and burning the rom and putting on rom chips that will at the very least serve as process of elimination and tell me if this is all a waste of time or not. According to what I read from Zerosquare, on actual ROM chips it should in theory work fine. thanks
  9. ok so from what I understand from the info you provided here this in fact IS a testing issue. (it's the skunks fault!) From what I gathered from Zerosqaures comments in that thread burning this game in it's current state to rom chips it should work just fine. obviously this isn't a solution to the testing issue but with that in mind I have to wonder, I use the universal boot header with my games. Is the universal boot header ROM width set to the correct width out of the box, or would that need to be modified as well if I'm going to use it? @SCPCD You mention there might be performance issues when testing pulling the bmp data directly from ROM. in this case you only mean from SKUNK and not actual ROM chips right? I'll tell you what I'm going to do. I am going to apply the code snippet to my rapap.s file provided by ggn here. Then I'm going to test on Skunk. After that (provided that it does work on Skunk) I will split the rom and put it on 2 rom chips and use my tester board to see how it goes. I'll report back here how it all goes, if it works on skunk or if the code causes any issues on real ROM chips. thanks guys
  10. I am currently working on a 4mb rom but have ran into some issues on the testing side of things. For this project the amount of needed assets has well surpassed 2Mb so I decided to go for a 4mb ROM style game instead of my typical 2MB ABS. (so will likely be a cart only final) I first dug through ggn's tutorial concerning audio playback in RB+. All of the music tracks for this game are now designated ROM in the assets.text file and I followed the instructions on what to write for them to play correctly in the .bas for this project I am using Zeroplayer so for example in the assets file I have: ROM,SFX_ZOMBOOGIE,SFX_ZOMBOOGIE,ASSETS\zombieboogie.raw and in the .bas file when it's time to play the audio I have: SNDZEROPLAY(2, (void *)SFX_ZOMBOOGIE, (SFX_ZOMBOOGIE_end-SFX_ZOMBOOGIE+3) and 0xfffffffc, 35000/4000, Zero_Audio_8bit_Unsigned|Zero_Audio_Looping) YES 35000/4000 is perfect and it IS a .raw file. This works absolutely fine in Virtual Jaguar. It hammers it out with absolutely no audio issues whatsoever, however when I try to load the binary onto my skunk and test it out on real hardware I get complete garbage feedback and noise where the music track should be and all of the sounds that have are designated ABS in assets are playing fine on top of the garbage noise. another thing I am trying to do is force feed a high resolution background animation using a trick I picked up from another thread. for this however I seem to be having the same issue. the 6 individual frames are written in the assets file as such: ROM,BMP_FRAMEA,gfx_clut16,ASSETS\hallframeA.bmp ROM,BMP_FRAMEB,gfx_clut16,ASSETS\hallframeB.bmp ROM,BMP_FRAMEC,gfx_clut16,ASSETS\hallframeC.bmp ROM,BMP_FRAMED,gfx_clut16,ASSETS\hallframeD.bmp ROM,BMP_FRAMEE,gfx_clut16,ASSETS\hallframeE.bmp ROM,BMP_FRAMEF,gfx_clut16,ASSETS\hallframeF.bmp ROM,BMP_SKINWALKER,gfx_clut16,ASSETS\ranch.bmp in the .bas file you can see me pointing to the individual frames for the background object with the following counter sequence: select case halltimer case 0 RSETOBJ(HALLWAYBG,R_sprite_gfxbase,(RGETOBJ(frameA,R_sprite_gfxbase))) RUPDALL case 4 RSETOBJ(HALLWAYBG,R_sprite_gfxbase,(RGETOBJ(frameB,R_sprite_gfxbase))) RUPDALL case 8 RSETOBJ(HALLWAYBG,R_sprite_gfxbase,(RGETOBJ(frameC,R_sprite_gfxbase))) RUPDALL case 12 RSETOBJ(HALLWAYBG,R_sprite_gfxbase,(RGETOBJ(frameD,R_sprite_gfxbase))) RUPDALL case 16 RSETOBJ(HALLWAYBG,R_sprite_gfxbase,(RGETOBJ(frameE,R_sprite_gfxbase))) RUPDALL case 20 RSETOBJ(HALLWAYBG,R_sprite_gfxbase,(RGETOBJ(frameF,R_sprite_gfxbase))) RUPDALL case 24 halltimer=0 RUPDALL end select this is supposed to be rendering the individual frames to the background every 2/2 seconds. The objects frameA-frameF have the correct sprite index in the rapap.ini file and remain inactive through the entire loop so we are only using them to point to the .bmp files here. this trick works FINE in Virtual Jaguar. In fact it looks really bad ass and seems to handle the whole process quite well but when I try and load to skunk and test on real Jaguar hardware I get a distorted image with large grey bars running through the animation. Everything seems to be running at full speed and you can kind of see the animation but it's like the image files are not making it all the way through. I do not want to try packing these bmps and using powaunpack because I am already packing a whole bunch of other stuff and anyway doesn't that automatically go into RAM in packed form? I don't want to do that. I also noticed that it will not allow me to set more than 7 audio files to ROM in the assets file. I ended up doing all of my music tracks here as ROM and left all of the regular sound effects as ABS. If I try to designate any more than 7 audio files as ROM I get a build error message saying this: Is there a reason for this limitation? What am I doing wrong with ROM vs ABS for this project in this case? It seems to me that this is some sort of compiling error on my part in that I am not telling it what to do with the files starting with ROM. But if that is the case then why does it all work flawlessly in Virtual Jaguar? Is there something special I have to do with my skunk in order to test this correctly? I did try the following build instructions build.bat JZ2 sendy build.bat JZ2 rom sendy build.bat JZ2 rom unpacked sendy all of these gave me the same exact results, so is there a compiling step I have missed or a RAM vs ROM rule I haven't learned yet? please help.
  11. World Tour Racing eh? Maybe a Zero 5 and Iron Soldier 2 ROM thrown on there as well? Maybe even Protector SE. HELL just one magic link to give you everything. I hear ya man. I think Carl from Songbird might have a link you can use. Try reaching out to him.
  12. I will consider the rotary option. This game uses Zeroplayer so I may need to reach out to omf for tips on getting that started. As of right now it's not a very extravagant project. The goal is to make a 1 to 1 replica of the Arcade game. I do plan to fix some of the bad/broken things from the original such as the lack of 3 final stages, it's so weird how they did it you can tell there should be 3 but yet there is only 1. Also level 13 is really messed up, tacky and unfinished. This will be fixed in this version. I guess this all comes down to it being an arcade prototype vs a full production release. There are other things that I will leave in for the sake of true conversion like the red and black text blocks and sloppy layout of stats on the transition screens. I will also include some special options that will be unlockable similar to some of my other releases. This game will also use save states via the save chips (I bought a ton of these for another project) High score should be saved as well as the trinkets and options you unlock. I really wasn't expecting too many folks to be interested in this game and only started it because I found it to be a bit relaxing. I'm surprised at the overall interest to be honest. Also I'm not sure why I find this particular game relaxing to work on.... It's a bit strange. Perhaps it's just the task of emulating something already made or maybe its just the fact that I'm looking at all of these colorful fish that does it for me. Whatever the case may be I do enjoy the experience so expect an update here soon when I have something more to show. I have done quite a bit since my last post, but I'm not ready to reveal anything just yet. Thanks for all of the great feedback.
  13. For some reason I WAS thinking SE was for second edition and not SOUND ENGINE. I thought you were referring to your latest version. Silly mistake on my part sorry. As for the input delay and controller functions example in order for both players to press keys simultaneously on jagpad 1 and 2 there needs to be a delay set up using U235. I could be WRONG but I don't recall having to do this with Zeroplayer. It seems to just work. I am going purely off memory here but I am certain I did NOT set up a delay on ZP and it worked and in order to do the same thing with U235 I had to set up a delay. I assumed this was due to the higher BUS usage on the U235 players end. BUT it is all speculation on my part admittedly. So if I'm wrong feel free to correct me. An added note the file size for unsigned audio files can be much smaller than signed which is why I would want to use some signed and some unsigned.
  14. I am not using U235 SE. I am using RB+ which has a much older version of U235 associated with it. I have not had the opportunity to work with the newest revison of your soundplayer. ggn did provide me a version of RB+ that incorporates the newest version of U235 however due to the most recent changes you made to it, it does not work 100% with RB+ as of this writing. Things that worked before are now broken and such. It does work but many many crashes now. I have been meaning to play with it and report the exact errors to ggn so he can properly incorporate it into the next RB+ package but I have been very slack in actually trying to do that. So with that being said if I want to use MODS or the U235 player I am currently stuck with the older version. I wasn't knocking on the player at all, I was simply stating that I prefer the Zeroplayer as it is very generous on overall bus and you are able to play back high quality sounds with ease. To me it's just an easier player to work with. I have never once had an issue with it, it always does exactly what I want it to do. Sometimes what I want it to do doesn't necessarily sound all that great but I never find myself fighting with Zeroplayer. It's pretty cut and dry. Another thing I like about it is with yours in order to do certain controller functions I have to set up an input delay. From what I have found using Zeroplayer I don't think that's necessary. Maybe it is and Zerosquare has it automatically doing that somehow but I don't think so. I also like the fact that omf was able to get rotary functions working using the Zeroplayer. I have been playing with this too, but I'm not quite there yet. So U235 (older version not SE) you have the ability to play MOD files and rotary support right out of the box but I find the playback can be finicky at times and from what I can tell if you aren't using signed audio files you aren't going to get a desirable sound. With Zeroplayer it takes pretty much anything I throw at it sounds great and is more user friendly. The downside is no MOD support and if you want rotary you have to do some extra steps. So really for me it's just a personal preference at the moment. But neither player are by any means laughable and certainly don't warrant a "hahaha" remark by anyone, which was the point I was trying to drive home.
×
×
  • Create New...