SMB 1 sprites

[PixelPiledriver]

Could you give some positive comments on why you chose Blitzmax? I know thats a little vague.
The website has lots of information but just some perspective would be educational.

Thanks for the link jad.

[Arne]

BMX is nice and scalable for me. Perhaps it can be said to be a mix of C++ and regular BASIC. It does not have any 'game making' features with editors or such, so you'll have to program engines from scratch. At least that's what I do. It uses open GL for gfx, so there are a few things to think about there. Pixel gfx is basically textures and stuff handled by the GPU. Fast. Programming palette swaps and pixel manipulation is a bit trickier.

I grew up with C64 Basic, Amiga Basic, Amos, etc. Seemed natural to use BlitzBasic after that. I've tried a lot of other languages, but I come back to BMX. It's easy to get results early, and you can still do complex stuff thanks to the OOP features (Classes, inheritence, linked lists, function pointers, etc.)



I just spent some time struggling with jumps. Up until now my lazy implementation was to just make the actor jump if a button was held and there was ground contact. However, it looks bouncy. Normally in games I think you have to release the button and land to recharge the jump. However, after having implemented that I missed a lot of precision jumps because I hit the button just a little too early while in the air. I don't think I want to program a look-ahead system which checks if the actor is about to land on a block or not. It could be useful for implementing a preparing-to-land animation frame though.

I think I'll do this instead: After the actor lands, it will spend a brief moment landing (and probably sliding). I could actually check the hardness of the landing here and use different animations, bending the knees more or whatever. The brief time spent in this state will negate the unrealistic instant bunny jumping feel, while allowing players to make single block jumps with less frustration.

That's the theory anyways.

[Arne]

Uploaded a test build. Windows.
http://androidarts.com/smb/

Quick placeholder stick-man included.

Edit: These friction, gravity and movement speeds are just for showing off the character animations, sliding, changing between states etc. Deliberately floaty and slidey. Next build I might put them in a text file.

[PixelPiledriver]

awesome 
Nice editor
Thanks for the insight. I've returned to school pursuing an RTIS degree. Perhaps in a year or so I'll check out Blitz.
I really appreciate you posting the programming progress as well as the art. The elaboration on your challenges and solutions is also educational.

[Paiku]

Sorry, I have no critics.

Just wanted to point out that you're an inspiration.
Your sites are very educational and the way you remake old tiltes with new ideas and concept art... I love it!

Okay, go on.. and keep it up.

[Arne]

Took the bull by the horns and started adding roughs to a 256+256 tile sheet. Working on a new editor which will let me edit the maps easier. It's a pain to write editors though, so I'm thinking I should leave the editor simple and enable importing/exporting images instead. This way I can edit the map in PS as an image. Lasso move, copy large chunks, etc. I might either do it in 24 bit mode, but then I have to come up with a way to generate good colors. I could average the tile colors and make sure that all are unique. Or I could make a random palette, or I could let the user (me) make one. I could also work in indexed mode, in which case the palette doesn't matter. I wrote a BMP exporter for Cortex Command, but I don't know if I can write one which consistently loads BMP's saved from PS or so.

Another option is to use the Photoshop RAW format. It can be set up to be very straight forward. You need to know the dimensions and amount of channels (e.g. R,G,B or Index) when opening the RAW file though. Then any palette can be applied afterwards. Edit: worked!

[Arne]

An wild insight appeared. Whenever I do terrain tiles I kind of run off doing wild structural variations. However, somehow a tiled look with a few well made blocks always looks better. Maybe the eye likes structure.

So, this time I started doing the usual varied rocky hill thing. No matter what colors I dressed it up in, it just looked out of place. Mario needs structure, blockyness, a rigidity. But I didn't want to use the same tile for entire mountains.

So, I thought, what if I keep the structure of the original block design, but treat it as if it was a mass produced thing which has gotten exposed to wear and tear?

To do this effectively, I needed one more color so I could go a little quiet where I needed to. I nearly went for a dark to, but it killed the simple graphical feel. I hope that the yellow-orange which I added don't.

Anyways, I started playing up and down detail strength, pushing in and out chunks.

I think it works. The horizontal highlight on the top gets more emphasis, and the grit 'underground' won't distract as much or flicker/distract when scrolling horizontally.



The bushes look mighty simple now though. Maybe I should toss in that dark green Helm(?) suggested. But I don't want to slip down a slope and add aliasing or elaborate softening shadows to stuff.

Thinking of punching my yellow-orange up a bit in brightness (or brown down?).

[Arne]

Not sure if I should have background rocks like this or not. I'm tempted to Fade the BG colors into the sky a bit more, anyways. Probably turn them more blue so there's no question that they belong to the sky. Bit of a mess now, too with the noisy gritty BG blocks I threw together.


Edit:

[PypeBros]

lighter blue doesn't work very well for near-bg items such as lanterns, pipes and caves. I could work for the statues (although hinting them as fairly distant) and is definitely a must for hills in the current setup.

Also, breakable bricks look fairly flat compared to everything else you have touched. Maybe SMB3 could be inspirational on this.

[ptoing]

This is starting to look really interesting, I hope you keep at it

A nitpick I am having is that the darker greeny-blue on the pipes is too close to the black and looks not very nice on the sides where you are basically mainly repeating the outline of the pipe.