Bubble Bobble (W.I.P.)

Use this forum to share and discuss Uzebox games and demos.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Bubble Bobble (W.I.P.)

Post by nicksen782 »

Finally, I am officially announcing Bubble Bobble! The game was originally made in 1986 by Taito and has been ported to many different platforms.

Check out the different milestone versions as development continues! Play online. Instructions and play controls are included!
http://nicksen782.net/r_uzebubble.php

-- Mini Overview.
V1 - Title screen. Basic game physics. Start of main menu.

V2 - Improved main menu (proper labels.) Start of intro screen. Start of game over screen. Improved game physics. Sprite flicker/multiplexing. Can have 8 actors on the screen and 4 bubbles. All actor animation frames. Bubble animation frames. The draw order of each "bank" of sprites is shifted every 2 draws in order to help spread the flicker.

LIVE - May or may not work. Represents the newest version available to the public.

-- Sprite Flickering
So, I allocate 24 sprites in the Makefile. The eight actors take (4*8)=32 sprites but they are flickered. So, four actors (16 sprites) are drawn per frame. This leaves 8 "natural" sprites remaining per half. I use this to put 2 bubble sprites at the end of each bank. The flicker is worse at the ends and the bubbles are not as important. Additionally, with the draw order shifting and the placement of the bubbles, I've reduced most of the flicker. I may need to revisit this later because I will likely want to have more bubbles able to be on screen. I have 12 2x2 spritemaps on screen right now. That's pretty good for now I think.

Code: Select all

VERSION: V2:
Fri Aug 18 10:21:12 EDT 2017
GAME: BubbleBobble
AVR Memory Usage
----------------
Device: atmega644
Program:   44940 bytes (68.6% Full)
(.text + .data + .bootloader)
Data:       3619 bytes (88.4% Full)
(.data + .bss + .noinit)
I have appreciated greatly the advice that I have been given, especially recently. I hope to complete this game. Already I am doing things that I could port over to UzeZelda (which I still intend to finish someday.)

Sprite Flicker discussion: viewtopic.php?f=3&t=9380&p=27145
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Bubble Bobble (W.I.P.)

Post by L4rry »

Nice! This looks really promising. From memory of the game, the graphics look spot on. When I started the game play test I almost wished the full game into existence :mrgreen:
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Bubble Bobble (W.I.P.)

Post by nicksen782 »

L4rry wrote: Fri Aug 18, 2017 3:48 pm Nice! This looks really promising. From memory of the game, the graphics look spot on. When I started the game play test I almost wished the full game into existence :mrgreen:
THANKS!

So, I've added SD card support with sd base and come up with a way to store all the level tiles and the screen map data on the SD card.

Pointers, RAM Tiles, and Mem*
So, use SetUserRamTilesCount(3); to reserve 3 ram tiles. Copy what was in ram tile #0 into ram tile #3. Read the new level tile into ram tile #0. In vram, the first ram tile is 0x00. Point it to the 3rd ram tile by going through vram and adjusting 0x00 to 0x03. Now the old level (still on screen) is still being displayed with the old ram tile (which was just moved.) Read in the new level data row by row from the SD card into ram tile #2. Make adjustments within each row to make sure that tile#0 is ram tile #0 and tile #1 is tile #0. It's a little switch-er-roo game really. Write those 30 bytes from ram tile #2 into vram at the bottom row of the screen. Now, shift all of vram (except the topmost row) up then erase the bottom-most row. Keep on doing this until the last pass at which point you wouldn't need to shift vram up. When done you can just reserve 1 ram tile for the level tile. You lose a ram tile but gain the level tiles of the entire game.

So, yea for pointers. Shifting vram wasn't that rough actually. In the past I would use for loops. Now, I use a pointer to the second row of vram and the 3rd row of vram. Then use memmove to literally shift the array in place so long as you make sure to copy the correct number of bytes.

I've found great use of memmove, memcpy, and memset lately.

I have a demo video online of the level shifting. It just goes through the first few levels (and the intro stage right before level 1.) I'm building the function into one that I can easily call for loading the next level once a level has been completed.

Check out the video link below!

-- Game page
https://nicksen782.net/r_uzebubble.php

-- Direct link to new video
https://nicksen782.net/UzeBridge/NICKSE ... demo1.webm
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Bubble Bobble (W.I.P.)

Post by D3thAdd3r »

Cool it's looking good!
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Bubble Bobble (W.I.P.)

Post by nicksen782 »

UPDATE:

The game levels are 100% ram tile really. I use 3 to load. 1 for the old tile, 1 for the new tile, and 1 for the tilemap data to scroll in. Afterwards I only maintain the 1 ramtile. The levels themselves are not in flash which is a good thing.

I've been working on the non-gameplay stuff. I have scrolling credits, curtains that can go up and down, the scene where you save your GFs, and the "Thank You Dance". Additionally, I've been shifting around tilesets so that the title and all text-based screens are in the same tileset. I've minimized the tile redundancy that way. Also, the final boss... I shrunk him down to a 4x4 tilemap instead of the bigger original one.

The Bubble Bobble logo has been edited heavily to reduce the number of tiles that are needed. I was at 59k (without the music engine.) I needed more flash. So, I decided to work on drawing tilemaps where the tile values come from SD instead of flash. This would be similar to what I had accomplished with UzeZelda. However, this version uses significantly less ram (from ram_tiles) to load since screens only scroll upwards. I draw the top line of the image at the bottom of the screen and then I shift vram up and repeat until the image is loaded. As for non-scrolling parts I just draw it. I can now do this with X, Y coordinates so I can put an image anywhere.

So, I converted the large tilemaps for credits 1, credits 2 and the title Tatio logo and text underneath to use this functionality. I'm still working on the logo (it scrolls downward) so it is still in flash for the moment.

As in all, I'm at 53k WITH the music engine turned on (inline mixer, all channels.) I know that I could probably do some further optimizations but I have most of the game complete. At least the visual and "animation" elements anyway. I will likely remove parts of the game because of flash limitations.

I need music and sound effects. I found the complete set for the game but I do not know how to do Uzebox music conversions.

So, that's where I am at. When I can finalize this scrolling from SD tilesets stuff I'll put up another demo and video.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Bubble Bobble (W.I.P.)

Post by nicksen782 »

I look forward to sharing my current technique for creating what I'm calling "Ram Tile Maps." Using this I have eliminated lots of single use tiles from FLASH and also added the ability to do animation from SD! I've attached a graphic to demonstrate. There are 5 frames and 5 ram tile sets. This has obviously terrible redundancy but the speed is not even a problem. Perhaps I could make things more efficient since only the glasses part (6 tiles which are the same 6 tiles on both sides) change. I would need to somehow replace only the required ram tiles. I may do this later if the SD size gets crazy. Until then, I've actually done more with this. You'll see that later.

lensflare6.gif
lensflare6.gif (91.08 KiB) Viewed 17622 times

NEXT: What is the present state of the SD music streaming? I would like to experiment with that in Bubble Bobble. Also, I'm not sure how to get started with midiconvert.
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Bubble Bobble (W.I.P.)

Post by L4rry »

Also, I'm not sure how to get started with midiconvert.
I used midiconvert for Iros. You first need to make sure your source tracks are already in midi format. What I did was to take the original midi for my song and load it up in Anvil Studio. I then chose 2 tracks and filtered out the rest (tracks map to channels) to get only the essential stuff and save space. But I definitely recommend you read this wiki entry by D3thAdd3r. It's quite comprehensive and it's what I used to figure things out: Music Step By Step
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Bubble Bobble (W.I.P.)

Post by D3thAdd3r »

Nicksen782 wrote:What is the present state of the SD music streaming?
Originally I was too optimistic to so intimately and blatantly link "SD" with "music streaming". In most all cases it only makes sense the source of music storage is on SD(the only other possible method that saves space is via network or procedural generation), but some tests with Artcfox revealed that simpleSD does not have the functionality required for a true SD streaming solution that works in most games. I thoroughly believe the streaming solution has been delivered and works well(music from a '644 ram buffer, agnostic to the source), but the piece that fills the buffer has not. I don't have enough interest to develop some asm version(which would basically be a state machine that does not wait, and picks up where it left off next call) over the top of simpleSD. As I see it, this is the only way to avoid the long blocking inter-sector delay; that part has to be made non-blocking. It is easy to do with SPI ram because you can afford to wait, and it is always a known delay. So I retract my mistake in making it seem like direct streaming from the SD would be easy with current code; that was an oversight on my part, but the buffered and conversion stuff works perfectly AFAIK. I will add an SPI ram streaming demo and remove the SD streaming demo.

I think people already know my "politics" by now, and that I am very much doing things the bigger easier way with the SPI ram for anything possible...I just feel like we have plenty of limitations already, and the things that can be done with SPI ram are every bit as clever and crafty as the ones used to avoid it's necessity.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Bubble Bobble (W.I.P.)

Post by nicksen782 »

I'm all for using SPI RAM. But, I do not yet have that hardware. I have requested it. I test on hardware too and if I do not have the appropriate hardware then all I have is the emulator. Granted, I like the emulator just fine and have a pretty decent system for using it.

Perhaps something like "SPI RAM not detected. Music will not be available" or something.

So, streaming from SPI RAM is more likely? You would still need to create the ASM state machine for that?

At this point I've been able to "stream" graphical animations from SD. I love the concept but it really only applies to "non-action" screens where whatever is happening is fully scripted or something.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Bubble Bobble (W.I.P.)

Post by Artcfox »

Please don't remove the streaming SD demo, I find that very usable, and I plan on incorporating that into future games! I wrote a real-time wave streamer that uses interrupts and uses that same paradigm, and it functions across sector boundaries even when playing at a 88.2 KHz sample rate. I don't think it is as unusable as you think it is.
Post Reply