New Game: Bugz

Use this forum to share and discuss Uzebox games and demos.
User avatar
Artcfox
Posts: 1051
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New Game: Bugz

Post by Artcfox » Sun Oct 11, 2015 4:33 am

D3thAdd3r wrote:I also found level 5 seems noticeably harder than level 6 and somewhat harder than level 7, but not necessarily needing a fix. On the subject of learning a step before it need to be exploited in more difficult situations, which always makes me think of Shigeru Miyamoto's genius designs, would a demo "attract mode" be possible with the existing flash space? They wouldn't have to beat the levels, but someone struggling thought willing to invest some time watching might learn some trick from that and think "hey, very cool!".
It might fit if I used some sort of RLE compression on an input capture file. That would indeed be a pretty sly way of passing on some tips and tricks.

As silly as it sounds, I was hoping to use the extra flash space for the Uzebox logo and sound, but that bumps me up over 60K, so I'm not sure I could do that without implementing that part myself, rather than using the canned routines to do it.

User avatar
D3thAdd3r
Posts: 2437
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: New Game: Bugz

Post by D3thAdd3r » Sun Oct 11, 2015 5:31 am

AE was a quick recording hack but it was space efficient and I think demos were on the order of ~100bytes(though stored on SD). Basically 1 byte of pad state and 1 byte of frames to hold that pad state(the "RLE" part of it), if you really felt like efficiency, you could get away with 5 bits since there is only 1 action button. I implemented something that spit it to eeprom where I manually ripped it by discarding the 2 byte ID in between every 30 bytes of demo data. Pretty fast to implement, though actually recording and assembling the data together took a bit, was tedious, but at the end worth it.

User avatar
D3thAdd3r
Posts: 2437
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: New Game: Bugz

Post by D3thAdd3r » Sun Oct 11, 2015 5:40 am

On the Uzebox logo, you might save a bunch of flash if you implement a custom one with ram tiles reusing some of your bug sprites. You could probably replicate the existing one as well with 4bpp graphics and some small code to save a bit. The pain with pallet stuff right now is there isn't good tool support so you might have to mess manually with the graphics using text replacement to get the colors you want.

User avatar
Artcfox
Posts: 1051
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New Game: Bugz

Post by Artcfox » Sun Oct 11, 2015 7:14 am

D3thAdd3r wrote:AE was a quick recording hack but it was space efficient and I think demos were on the order of ~100bytes(though stored on SD). Basically 1 byte of pad state and 1 byte of frames to hold that pad state(the "RLE" part of it), if you really felt like efficiency, you could get away with 5 bits since there is only 1 action button. I implemented something that spit it to eeprom where I manually ripped it by discarding the 2 byte ID in between every 30 bytes of demo data. Pretty fast to implement, though actually recording and assembling the data together took a bit, was tedious, but at the end worth it.
Cool. I would really want to show off the P1 VS P2 mode, but getting an input capture of that will be tricky, and might have to involve multiple keyboards, because if too many buttons are being held down at once then it locks out any new keypresses, making it impossible to play in the emulator. Or I could try rigging something up with my logic analyzer and the real hardware to capture both players' inputs from the real system.

And it seems that the input capture feature completely ignores player 2. :(
D3thAdd3r wrote:On the Uzebox logo, you might save a bunch of flash if you implement a custom one with ram tiles reusing some of your bug sprites. You could probably replicate the existing one as well with 4bpp graphics and some small code to save a bit. The pain with pallet stuff right now is there isn't good tool support so you might have to mess manually with the graphics using text replacement to get the colors you want.
Hmm, it looks like I can fit it as is, especially if I disable Channel 5, which should even save me some cycles! The only problem is the intro is hardcoded to use WAVE #8, but I've pared them down to just the 2 WAVES that I use. I have enough space to add the one it wants, but it certainly won't be WAVE #8.

Edit: I just checked, it saves hundreds of cycles, sometimes on the order of 600 cycles per frame, which is pretty insane!

User avatar
D3thAdd3r
Posts: 2437
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: New Game: Bugz

Post by D3thAdd3r » Sun Oct 11, 2015 7:54 am

Artcfox wrote: I have enough space to add the one it wants, but it certainly won't be WAVE #8.
At this point I don't think the logo is changing, maybe just -DINTRO=0 and copy the code/graphics/sound into a user Intro() with the appropriate sound effect wave change.
Artcfox wrote:I would really want to show off the P1 VS P2 mode, but getting an input capture of that will be tricky, and might have to involve multiple keyboards, because if too many buttons are being held down at once then it locks out any new keypresses, making it impossible to play in the emulator. Or I could try rigging something up with my logic analyzer and the real hardware to capture both players' inputs from the real system.

And it seems that the input capture feature completely ignores player 2.
I guess it would be best to add that in to Uzem, which probably wouldn't be too terrible to do. Time wise before setting up a logic analyzer and converter program, if you have an Arduino or something else that can act as a 5v UART<->USB bridge, simply enable the UART TX buffers and dump the bytes to PuTTY. Paste output into a hex editor, make a 0xFF demo end byte after(since you could never really push Up+Down+Left+Right), then repeat. Should be fast enough to scan through looking for 0xFF until you find the start of the demo you want once at level load. At least on the real hardware you don't have to worry about key jamming/roll over.

User avatar
uze6666
Site Admin
Posts: 4487
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: New Game: Bugz

Post by uze6666 » Sun Oct 11, 2015 5:13 pm

The safe bits each side of the fire pits are very narrow and I found that that they requires a lot of dexterity early on. Perhaps the grasshoppers could be the only things as there are already a lot of them. Or perhaps just keep the top fire pit?

User avatar
Artcfox
Posts: 1051
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New Game: Bugz

Post by Artcfox » Sun Oct 11, 2015 7:31 pm

D3thAdd3r wrote:
Artcfox wrote: I have enough space to add the one it wants, but it certainly won't be WAVE #8.
At this point I don't think the logo is changing, maybe just -DINTRO=0 and copy the code/graphics/sound into a user Intro() with the appropriate sound effect wave change.
Artcfox wrote:I would really want to show off the P1 VS P2 mode, but getting an input capture of that will be tricky, and might have to involve multiple keyboards, because if too many buttons are being held down at once then it locks out any new keypresses, making it impossible to play in the emulator. Or I could try rigging something up with my logic analyzer and the real hardware to capture both players' inputs from the real system.

And it seems that the input capture feature completely ignores player 2.
I guess it would be best to add that in to Uzem, which probably wouldn't be too terrible to do. Time wise before setting up a logic analyzer and converter program, if you have an Arduino or something else that can act as a 5v UART<->USB bridge, simply enable the UART TX buffers and dump the bytes to PuTTY. Paste output into a hex editor, make a 0xFF demo end byte after(since you could never really push Up+Down+Left+Right), then repeat. Should be fast enough to scan through looking for 0xFF until you find the start of the demo you want once at level load. At least on the real hardware you don't have to worry about key jamming/roll over.
I have a nice 5V Serial to Ethernet Gateway that I could connect and have it spit out UDP packets to my computer, but I was afraid that might change the timing inside my program, which is why I was thinking about doing something totally passive. As long as I'm making vsync every time though, that shouldn't be a problem?
uze6666 wrote:The safe bits each side of the fire pits are very narrow and I found that that they requires a lot of dexterity early on. Perhaps the grasshoppers could be the only things as there are already a lot of them. Or perhaps just keep the top fire pit?
Hmm, I'm thinking that I might just show the trick that I hoped people would discover. (Hint: It's really hard to jump up onto a platform with fire near the edge, but all of the platforms with fire near the edge have another platform adjacent to and above them.)

User avatar
D3thAdd3r
Posts: 2437
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: New Game: Bugz

Post by D3thAdd3r » Sun Oct 11, 2015 10:09 pm

Artcfox wrote:I have a nice 5V Serial to Ethernet Gateway that I could connect and have it spit out UDP packets to my computer, but I was afraid that might change the timing inside my program, which is why I was thinking about doing something totally passive. As long as I'm making vsync every time though, that shouldn't be a problem?
Now that you got rid of channel 5 you just stuff bytes to the Tx buffer which could be as small as 2 bytes, at which point the kernel automatically transmits each bytes once during HSYNC interrupt(which is why you can't have UART buffers with all sound channels enabled) from the circular Tx buffer. The user program is constantly being interrupted by HSYNC anyways for sound updates, so it shouldn't make a cycle difference.

User avatar
Artcfox
Posts: 1051
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: New Game: Bugz

Post by Artcfox » Sun Oct 11, 2015 10:43 pm

D3thAdd3r wrote:
Artcfox wrote:I have a nice 5V Serial to Ethernet Gateway that I could connect and have it spit out UDP packets to my computer, but I was afraid that might change the timing inside my program, which is why I was thinking about doing something totally passive. As long as I'm making vsync every time though, that shouldn't be a problem?
Now that you got rid of channel 5 you just stuff bytes to the Tx buffer which could be as small as 2 bytes, at which point the kernel automatically transmits each bytes once during HSYNC interrupt(which is why you can't have UART buffers with all sound channels enabled) from the circular Tx buffer. The user program is constantly being interrupted by HSYNC anyways for sound updates, so it shouldn't make a cycle difference.
Ooh, that sounds perfect!

User avatar
uze6666
Site Admin
Posts: 4487
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: New Game: Bugz

Post by uze6666 » Thu Oct 15, 2015 7:16 am

Man, those levels are hard..or I'm getting old! I really want to get through all levels.

My two cents: Now on level 7. I like the level, but having to go through those bugs over the pit twice seem a bit too hard at this point. Perhaps having a small opening at the top that you can sneak though to get to the final big cookie would be easier. Not that practicing jumping on those bugs is too hard, but early on in the game, perhaps having to do it once would be already an accomplishment. :) Unless I'm missing some trick?...

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests