WIP: Bubble Bobble

[Mike]

What? %p I can't get my imagery to picture MINIPAINT with a web interface and user accounts.

You completely forgot there's already a working native solution for editing graphics, sprite sheets in particular, on the VIC-20.

Coders and graphicians already teamed up ages ago to collaborate on game graphics, without "web interfaces" or "user accounts". For good pixel art, a graphician needs to understand the intricacies of the target's video hardware. Doing that on native hardware (or in good emulation) ensures the graphician ends up with workable results for the coder.

[pixel]

Ah! Here's how I missed it: morning coffee, "What was that with MINIPAINT?" *google* *denial* *chatGPT* effnoh...

[pixel]

Just shining some light on a potentially symbiotic project

I'm in with my latest sprite code which, I've heard, brings record-breaking performance and I want a blindfold before some shouts "FIRE!". Using a generalized sprite library for what's planned will give disappointing results. I'm really in just because of that. But I want something in return: a hires bubble sprite.

Also, I strongly recommend using a development environment that is cross-platform, namely cc65, GNU make aaaaand: github where we can track issues and have ppl rant from outside Denial. I cannot partake with Windoze (not as if Linux distros were usable for pressing office business lately). That's for building the project. It's irrelevant where the extra binaries (font/levels/sprites/background/images/sound) are coming from.

Hardware requirements: full memory expansion (+35K)
btw: the plus4 could be a co-target and I *know* we have able coders for that one around.

Things one could start off with right away in the non-programming department:
* level data: text lines of characters denoting background/enemy positions would suffice
* everything graphical
* audio
* figure out the original game mechanics: what comes when, how many points, how the enemies are moving. With numbers. Doodles are also great.

The original code is unreadable with cryptic Japanese comments so one could as well use the ROM disassembly as a crystal ball for game logic. And that's the bitch driving the car with hand brake pulled if you've been to the pub with colleagues.

Oh, another suggestion: hands off assembly as much as possible. C is perfect for the skeleton and most of the game logic. We'll have to get it to work first, especially when working in a team where Rain Man brains cannot connect.

It's pointless to ask if anyone would join. We have plenty of tasks that can be done by fans who don't code and if everybody invests an hour or two we'll have an amazing game very quickly.

Are we doing this?

[pixel]

I've set up a Git repo and called the thing "TEAM DINO" as it's supposed to be a team effort all the way. And those copyright issues which shouldn't be any more.

https://github.com/SvenMichaelKlose/team-dino

EDIT: I put the sprite code of ARUKANOIDO in which I ported halfway to ca65 – a task that's ideal for the moments when creativity has been exhausted but the fingers want to move. That's why I'm not worried about my spare time that goes into this. Now back to TUNIX...

[scalz8]

Hello, I've tried to join the Git repo and to create a folder where to insert my contribute, but didn't manage.
It mentions something like I do need to push access to the repository.
Sorry, I am not a developer. Just a funboy.

Nevertheless, I would try to contribute by sharing my code, and my sprites.

To answer your request, I've tried to attach here a proposal for the sprites...I feel ashame...it was an excel file... sorry for that.... but it is not possible to attach such a file here. Please, let me know how I can share it with you. I can also share the BASIC code of my demo.
In the while, I share two screenshots now here.
I have tried to introduce the bubbles sprites, for Vic20: 2 versions for the bubble with and without the monster inside.

I am pretty sure the values provided are autoexplicative..!

[pixel]

Hello, I've tried to join the Git repo and to create a folder where to insert my contribute, but didn't manage.
It mentions something like I do need to push access to the repository.
Sorry, I am not a developer. Just a funboy.

Most devs seem to carry their spine upside down, so I guess fun boys aren't rare in that department.

You have to fork the repository under your account to make changes and issue a pull request for me to act upon. If you're comfy with Git (I have too look into the manual every other day if I need something else but my three regular commands) you can also get write permissions. But I prefer the pull way we all cling to to avoid accidents.

Nevertheless, I would try to contribute by sharing my code, and my sprites.

Yay! Welcome to Team Dino!

To answer your request, I've tried to attach here a proposal for the sprites...I feel ashame...it was an excel file... sorry for that.... but it is not possible to attach such a file here. Please, let me know how I can share it with you. I can also share the BASIC code of my demo.
In the while, I share two screenshots now here.
I have tried to introduce the bubbles sprites, for Vic20: 2 versions for the bubble with and without the monster inside.
Snap 2024-06-11 at 10.59.45.png
Snap 2024-06-11 at 10.59.38.png
I am pretty sure the values provided are autoexplicative..!

This board unfortunately accepts only some image formats and ZIP archives which is a pity as many PRGs are already compressed with exomizer and any modern mouse pointer consumes more memory in total.
The Excel format is a bit impractical. A CSV export on the other hand would integrate much better with the rest – in case they need to be converted by some script later, e.g. to change colour values.
Mike will sure as hell help out should you want to try his MINIPAINT which has the advantage of being as close to the original display as it can get, so you can find neat tricks (usually by accident) and that would resolve any file format worries. Plus you can test animations without need for an eidetic memory.

But can we have that CSV first?

[scalz8]

Try this dropbox link:
https://www.dropbox.com/scl/fi/qrhkxlue ... j5lu9&dl=0
for the csv

This for the zip file with many stuff..
https://www.dropbox.com/s/fv8dxzlkgn666 ... t.zip?dl=0

[pixel]

Try this dropbox link:
https://www.dropbox.com/scl/fi/qrhkxlue ... j5lu9&dl=0
for the csv

This for the zip file with many stuff..
https://www.dropbox.com/s/fv8dxzlkgn666 ... t.zip?dl=0

Thanks. But I'm one of those who won't create new accounts in random places when an attached ZIP would do.

[scalz8]

Understood. So you can download just the first csv file.

[pixel]

This is all it takes. As the bubbles will be moving slowly they will probably look better in hires too. There's also no need for empty lines.

Code: Select all

00111000
01222100
01222100
01222100
01232100
12313210
12313210
01232100
01222100
01222100
00122100
00121000
00111000
00111000
00011000
00000000

[scalz8]

Got it. But one question: once we decide the resolution mode, shouldn’t it be always the same? I mean: if the dragon is in color mode 4x8, I assume we can’t have the bubbles in hi-res… so if we decide to use the hi-res, we should change the “sprite” of the dragon, as well…. In that case I’ve tried but couldn’t find the way to have an acceptable dragon with hires… while with the color mode I think the result shown at the beginning of this discussion in the BASIC demo looks decent,in my opinion..

[pixel]

Got it. But one question: once we decide the resolution mode, shouldn’t it be always the same? I mean: if the dragon is in color mode 4x8, I assume we can’t have the bubbles in hi-res… so if we decide to use the hi-res, we should change the “sprite” of the dragon, as well…. In that case I’ve tried but couldn’t find the way to have an acceptable dragon with hires… while with the color mode I think the result shown at the beginning of this discussion in the BASIC demo looks decent,in my opinion..

You can actually choose for each character on the fixed text grid if you want multicolor or hires. If hires and multi chars compete for a particular char it'll get mixed up. That doesn't matter too much because the bubbles won't get over the multicolor wall and usually they pop when touched. Barely anyone will notice when in on the action.

What's also rather not necessary is to draw mirrored versions of sprites, by the way, just in case...

[scalz8]

Great info. I was not aware of that. So does it mean we can use the dragons in color mode and bubbles in hires? Sounds fantastic. Ok also for the mirrored images. I will! Not in these days for family reasons but I will

[pixel]

Great info. I was not aware of that. So does it mean we can use the dragons in color mode and bubbles in hires? Sounds fantastic. Ok also for the mirrored images. I will! Not in these days for family reasons but I will

Cool. A dragon, an enemy, a bubble... a bonus was also there. That's enough to cause trouble in the coding section.

This is just the right moment to mindlessly continue porting the sprite code to ca65 a bit...

[beamrider]

This is just the right moment to mindlessly continue porting the sprite code to ca65 a bit...

Your sprite code seems to be very fast. Once ported to CA65? perhaps it should have its own repo along with some basic instructions and a demo program?