Beta Bubbman 2

[Esn]

I think it should be an option that pops up when you start the first time (only the first time), and whatever the user chooses is saved as default for later (but it should be possible to change this default, somewhere). While almost all Pandoras should be able to go to 700Mhz, some may not.

 

[Tempel]

Oh, I think that would be a hassle. I'd either have to hook in to libpnd or call a shell script to do the changing; much more than adding one line to the PXML generator. Besides, I thought that launching an app with specified clockspeed would automatically ask for confirmation. Granted, it doesn't save the result and asks every time (or so I vaguely recall), so maybe that would be irritating. But so would having to remember to change it manually before every run.

That's it, I'm going to upload it as-is, we can debate this ad nauseum, and I can update it if need be.

EDIT: Here it is on the file archive. I haven't yet been given upload rights to the app store (but I only requested them today, so let's be patient).

 

[WizardStan]

I think it should be an option that pops up when you start the first time (only the first time), and whatever the user chooses is saved as default for later (but it should be possible to change this default, somewhere).

Oh, I think that would be a hassle. I'd either have to hook in to libpnd or call a shell script to do the changing; much more than adding one line to the PXML generator. Besides, I thought that launching an app with specified clockspeed would automatically ask for confirmation. Granted, it doesn't save the result and asks every time (or so I vaguely recall), so maybe that would be irritating. But so would having to remember to change it manually before every run.

Actually, it already does that
If you set the clockspeed in the PXML, when you run it you're presented with a dialog and a bunch of options along the lines of "This application is setting the clock speed, would you like to (A)accept for now, (B)accept and never ask again, (C)reject, (D)reject and never ask again, (E)custom set it"
I forget the exact options and I'm too lazy to look it up right now, but that's the gist of it; libpnd (as of HF4 at least) takes care of all the magical hooking and stuff for you.

 

[Tempel]

Well, consider me impressed. I've added the clockspeed specification to the copy on my site, and the one on openhandhelds is being processed.

 

[WizardStan]

Yes, set it to 700 MHz
Yes, select custom value
Yes, set it to 700 MHz and don't ask again
Yes, set it to custom speed and don't ask again
No, don't change the speed
No, don't change the speed and don't ask again

Perfect

 

[zRichi]

This is absolutely amazing!
I've started my first Pygame now so hopefully I can figure out how to PND it etc.

 

[Magic Sam]

Hi,

Great game, thanks for porting it Brings back memories of Adventure Island on Game Boy !

Too slow even @ 800MHz IMHO, what could we do to speed it up ? Are there any command line options to turn some stuff off (music, snow flakes, etc) ?

Bye, and thanks again !

Magic Sam

 

[Tempel]

No built-in command line options to improve it. I did just notice that all the sprites seem to use per-pixel transparency, which is really rough on SDL/pygame performance (I also just noticed that the clouds and bushes are the same ). Unfortunately, optimizing this is not a priority for me, especially without a Pandora on hand, but the code and assets are available for anyone who wants to have a go. Note that you'd have to change the sprites to a colourkeyed background, then change the code to apply the colourkey and blit without alpha.

 

[Magic Sam]

Hi,

@ Tempel: what do you mean by "changing the sprites to a colourkeyed background, then change the code to apply the colourkey and blit without alpha" ?

Is alpha the transparency layer ? And is the blit you're talking about this blit ?

Finally, is this something one could do with a bitmap editor like GIMP (without the code change) ?

Bye, Magic Sam

 

[pymike]

The OP contacted me about this port, so I thought I'd post here real quick.

I'm not supporting any of my old Python games right now, so don't expect any official new updates. However, I thought I'd give you guys some quick pointers on how to optimize the image code if you're really interested in doing that.

The images in BubbMan 2 are stored in several different spritesheets. At the time I decided to use transparency as the background since it was quicker for me to draw that way (I made the game under a competition deadline). Using colorkeys would definitely speed it up quite a bit. Here's how:

Open up each of the images in GIMP (or some other image editor that supports transparency) and replace all of the transparency with a color that's not being used in any of the sprites. Pink's a good choice, since that's rarely used (if it is, just make it a different shade). It's very important that the same color is used in all of the images.

Next, in the image loading code (pretty sure it's in retrogamelib/util.py), change .convert_alpha() to .convert(), and add this line below:

image.set_colorkey((255, 0, 255), pygame.RLEACCEL)

This line basically makes it so that all of the pink colored pixels in the image are transparent. You can change the RGB tuple (255, 0, 255) to whatever color you chose for the transparency in the sprites. Just make sure they're the same in the code and in each image. It might take a bit more work and tweaking to get it working, but I'm pretty sure that's all you need to do.

Cheers! Glad you guys are having fun with this.

 

[Tempel]

Hey pymike! Thanks for the tip (and the cool game). I had wanted to tell you about this port, but couldn't find any contact info for you.

Anyways, now that I have a clue of where to look in the code, I'll give the conversion a go. You might hear from me some time tomorrow evening.

 

[Tempel]

I guess it's tomorrow evening already because it's done already. That was actually really easy (if somewhat tedious to change all the images); thanks again for the insight pymike.

Testers, let me know if it runs any better at lower clockspeeds. I realize now I forgot to remove the 700MHz specification from it, so it'll still bother you about it. But try various speeds, and tell me what works best; I'll add the appropriate speed (or remove the speed entirely) for the next version that I upload to the archive.

 

[pymike]

Great! Glad you got it working. Just shoot me an email if you have any more questions.

Cheers.

 

[007jaws]

hi thanks for this, the new version has some graphics missing e.g. the fishes in the game used to come out of the water and kill you or you kill them now they are not there at all, you keep dieing and invisible fish kills you?, there maybe other characters in the game missing?
the previous version was fine

cheers bud hope you get this fixed and back up and running

007jaws

 

[WizardStan]

I don't really notice a major speed increase, unfortunately
Maybe there's some other bottleneck that we can look at.

 

[Tempel]

No perceptible speed changes at all? Any guesses about what further changes could help? Perhaps it uses alpha blits internally, like for temporary surfaces; I'll have to look into that at some point.

Regarding the missing fish: they're appearing just fine on my end. Can anyone confirm if they're appearing or not on the Pandora? If you'd like to check, there's one that appears in the center of the very first body of water in the very first level. 007jaws, if you're dying unexpectedly, it might just be from loss of energy rather than an invisible fish. I haven't touched any code that determines whether you die, so (ideally) it shouldn't have changed between versions.

 

[Magic Sam]

Hi,

Thanks Tempel and pymike for this great game

Unfortunately I also have to report that this new version is buggy

Enemies bump on the background, there are large parts of sea that one can't cross with a jump, but you can jump and walk on the water :blink:

I'd say the game is a little bit faster @ 800MHz though !

EDIT: I can't complete the first stage because of a change in the level architecture...and I have no fish

Bye, Magic Sam

 

[Tempel]

Thanks Magic Sam. What do you mean by "Enemies bump on the background"? As for water, if you stand on it you're supposed to sink (and you die if you touch the bottom of the screen), but you can jump off freely. I think it's a valid strategy, not game-breaking.

But no fish? Change in level architecture? I've never seen that here! What's going on?!

 

[007jaws]

Thanks Magic Sam. What do you mean by "Enemies bump on the background"? As for water, if you stand on it you're supposed to sink (and you die if you touch the bottom of the screen), but you can jump off freely. I think it's a valid strategy, not game-breaking.

But no fish? Change in level architecture? I've never seen that here! What's going on?!

Hi I was playing level 2, don't know about magic sam?, but normally the fish come out the water and you throw a rock at them to finish them off but I cannot see any fish coming out in the whole level, i have compared this version with the previous one uploded on openhandheld, i can certainly for sure see fish in this level with the older version which was actually fine, no speed increase between the two versions?

Cheers!!

007

 

[pymike]

Hey Tempel, did you edit the level files? I think that might be causing some of these issues -- IIRC the level parser assumes that "nothing" is transparency. You may need to have them be in their original state and not use colorkeys when you load the level image file. For example, do something like this:

# retrogamelib/util.py

def load_image(filename, use_colorkey=True):
    if use_colorkey:
        # colorkey code here
    else:
        # old image loading code here

# lib/engine.py
retrogamelib.util.load_image("level_file.png", use_colorkey=False)

I don't own a Pandora and PyGame's not working on my iMac, so sadly I can't help you guys test anything.