[T-Bone]

Sure, no prob.

[T-Bone]

Here is an unrelated project, for the hell of it, Prince of Pershia.

Attached image(s)

• 

This post has been edited by T-Bone: 03 October 2014 - 08:04 PM

[T-Bone]

SM4MZX is here!

Attached File(s)

•  SM4MZXb.zip (226.13K)
  Number of downloads: 170

This post has been edited by T-bone6: 03 May 2004 - 04:03 PM

[T-Bone]

I'm currently working on the eight world's charsets. I'm killing myself to make this game for you guys!

This post has been edited by T-Bone: 27 December 2012 - 07:55 AM

[Pyro1588]

give us more than a few hours to download it. this isn't a really fast-moving community.

[Micah]

Well, the 2/3 of the Prince of Persia screenie that I can see looks pretty good.

As for Super Mario, it is a graphical goldmine. I think the background could have been composed of a little more than just clouds, but everything else looks peachy (especially for normal MZX graphics). The gameplay is choppy, though. It needs to be a lot smoother.

[T-Bone]

Because I can't use SMZX mode, the background has to be white orientated. So clouds are about all I could think of. No hills or such. The bushes and trees are actual things I wanted to be in the background, but there are graphical limits I have to consider.

This post has been edited by T-bone6: 03 May 2004 - 08:47 PM

[hob nado]

You could pull off stuff in the background just fine, if you gave Mario a background.

Played through the demo a little bit. Very nice graphics, but I'm expecting a little more in the gameplay department. Graphics aren't everything. The jumping was really choppy, and you can't interact with enemies yet...

[Tixus]

The physics of the game need a little work. Here's a list of possible improvements...

If an enemy hits Mario, he shouldn't just stand there (I know you plan on having him shrink, but the enemy shouldn't just bounce off). Perhaps something else could happen as well? Mario getting pushed back a bit when hit would give you more reason to try to avoid it, especially on close quarters.

Jumping needs a little work. It seems the jumping's slower when you jump with two arrow keys held down. When jumping straight up, however, it's too choppy. A good control scheme would be for the player to jump up to a given height for as long as the up arrow key is held down, then to wait for a moment for air time (As long as the player still holds the up key), then it would finally end in the descent. It's not necessarily Mario, but it'd make it easier to control.

There were quite a few enemies I didn't know how to kill. I don't know if you intended on them to be killed or not, but it'd be good if there were a specific way to get rid of the ones that you can't simply jump on. And on the enemies you can jump on to kill, perhaps Mario should bounce a little up in the air after jumping on them, so it's easier to tell the difference between when you actually land on one, and when you land on the ground next to it.

That's all I have for right now. Nice graphics, but the physics need a bit of tweaking.

[hob nado]

Yeah, what Tix said. You know how gravity works in physics, right? When a person jumps, he puts x amount of upwards force on himself, meanwhile, gravity is constantly accelerating him downwards at -4.9 m/s^2 (or was it -9.8? I forget). The upwards force is stronger than gravity for a moment so he goes upwards, but gravity is constantly wearing away at it until he's got no more upwards momentum, and begins to fall down.

I'm not saying you have to implement this number but your engine should emulate the basic effects of this: the jump starts out quickly, gradually slows down towards the top, a little bit of hangtime at the top, then gravity takes over and pulls him to earth with increasing speed.

Now, in a videogame, it's a good idea to not let gravity accelerate stuff forever - and in MZX, the limits of the system will force this on you already. Just have the descent speed up until one motion every given amount of cycles and keep that constant, the usual rate of gravity.

[Micah]

Yeah, it's -9.8 m/s. This shouldn't really matter though, because MZX cannot accurately depict gravitational pull. Just shoot for something that looks and plays good. Quick upward force, hangtime, accelerate on the drop.

[zombieguy]

That looks really, really nice... Hope to see it completed in the near future.

[T-Bone]

Here's the newest version of the BETA DEMO. Some of the problems you guys have found have been fixed. I added another stage too!

I'm working on the gravity probs right now for the next version. I'll have to re-do the engine. I'm kind'a new to SPRITEs so I may not get the jumping controls down packed.

I'm also going to create an effect for when you are harmed by enemies. You will blink and possibly be thrown back one x-axis space. And since Mario is composed of a SPRITE and a robot I can't really make enemies walk through you when you are in hurt mode (blinking).

By the way, all of you that have beta tested any of the versions posted here, will be entered into the credits of the full-version. I'm going to use your Digiboard usernames.

For the next version I am going to add a pipe level! Stage 7-1 (contains Human Fire Trap! You know those plants in the pipes.)

Attached File(s)

•  SM4MZXb.zip (250.5K)
  Number of downloads: 176

This post has been edited by T-Bone: 03 October 2014 - 08:06 PM

[T-Bone]

Next version due soon! No latter than May 20th

This post has been edited by T-bone6: 04 May 2004 - 05:46 PM

[T-Bone]

I may release ver 1.09 on Wednesdays or Thursday of this week.

For those have downloaded the demo, do read the reversion history to know what changes I have made.

This post has been edited by T-Bone: 03 October 2014 - 08:07 PM

[Exophase]

The graphics are of course excellent, I won't try to suggest anything better there.

Now, there isn't necessarily a right or a wrong way to do things here, but the way you're going about using sprites in this is at the very least making things much more complicated than they should be, and could be one of the reasons why your implementation of things is still rather minimalistic. You should really be using the builtin collision detection mechanism with sprites, and then make robots completely independant of their sprite entities and just move sprites around remotely. This is actually really easy and would use a lot less code.

You might be asking, "if I don't have robots with the sprite positions, how will I send them labels when things happen?" The answer is by naming convention. I name the control robots something like pN where N is the sprite number they correspond to. If you say, would collide with sprite N while moving normally you might send "pN" the "touch" label. If while jumping, you could send the "bump" label. Static entities that have fixed responses (like breakable blocks) don't need to have sprites mapping them of course; the collision mechanism will return -1 for customblocks too... you can then check what customblock (char range?) is at that location to see what to do. How about sending things to the north or another direction? The "if sprite" method works but only checks one space at a time. You can check entire spaces by using "sprite swapping"; doing a collision test with a filler sprite of the right size at the position you want. For instance, when you hit a block, it might test a sprite of collision size 2x1 directly above it to see if you hit a badguy too.

Your walking is way too slow. The problem is that even though you've exported the walking animations to another bot, you have the waiting between frames chained to the walking bot. The animations bot should have complete animation cycles and the walking bot should issue these and itself wait 1 or so inbetween movements.

You should really use partial charsets. It would save you a ton of grief; of course it's a little hard to transition now. Might not be so bad using in-MZX code to dump the charsets as they're edited to.

I strongly recommend not having so much light vertical scrolling in this game (for instance when you jump); you should either make the screen height smaller or (better) make the viewport larger. Also, you need not manually set the scrollview position with the sprite, there's a sprite command to do this for you:

"If you set sprN_setview to anything it will do the equivilent of "resetview" for the sprite N." (from 265_info.txt)

The rest of the "problems" you're probably already aware of and working to fix. So I'll let you to it.. good luck..

- Exo

[T-Bone]

Thanks! I'm new to SPRITES so I didn't really know what I was originally doing when I changed the engine from block robots to SPRITES. Do you think that independent SPRITES might slow the game down? Or will it make it a bit faster and less choppy?

This post has been edited by T-bone6: 04 May 2004 - 08:18 PM

[Revvy]

Well they certainly won't hurt it.

[Exophase]

T-bone6, on May 4 2004, 03:12 PM, said:

Thanks! I'm new to SPRITES so I didn't really know what I was originally doing when I changed the engine from block robots to SPRITES. Do you think that independent SPRITES might slow the game down? Or will it make it a bit faster and less choppy?

They definitely won't slow the game down, since you'd only be removing an element, not adding something..

- Exo

[duvel]

WOW! This is the first version I played, and the graphics are AMAZING. Congrats on that. Now to the things I discovered. As Exo said, the walking is too slow. Another thing I noticed was that you went behind trees and hills. If you're using a Mario sprite, change him to sprite number 255, so that he is drawn last. Other than that, you also need a bit of variety when it comes to pipe places. it would make it a much more fun game. After all, how many times can you kill the Hammer Bro before you get bored?

[T-Bone]

After work, I'll get to SM4MZX as quick as possible. I have to go now, so I'll see what changes I can make before the end of this week.


EDIT:
Removed radio show plug.

This post has been edited by T-Bone: 03 October 2014 - 08:07 PM

[hob nado]

Could you stop plugging your radio station please =) =) =) =)

[T-Bone]

I need a turtorial on SPRITE_COLLIDING. I can't get it to work.

[T-Bone]

Here's a mini fix ver of the demo. Walking is smoother and faster. fixed some hammer bro issues.

Attached File(s)

•  SM4MZXb.zip (250.47K)
  Number of downloads: 161

This post has been edited by T-Bone: 03 October 2014 - 08:08 PM

[Quasar84]

I just played this game, and it's looking very good. Your graphics are both good looking and functional, which I respect. The walking and jumping are greatly improved since the first version (though the difference between jumping vertically and jumping horizontally in terms of rise and fall speed is slightly troubling,) and overall the game is enjoyable. There are, as always, some things to take issue with, however. For one thing, if you jump right at the start of the desert level, you can see the turtle sprite. Likewise, in the desert level, quicksand evidently steals your soul if you fall in it. O_o I enjoy the ice level's mechanics, though. They're not precisely faithful to SMB3, where you could stop by jumping straight up or careful arrow pushing, but hey, given MZX's block limitations, it's understandable and it still plays pretty well. Overall, this is a good and promising game that, with tweaking, could be great.

[GetDizzy]

All i can say is...

Holy fucking crap.

BEST SIDESCROLLER FOR MZX EVER

in DosBOX, you seemed to have to sit on the enemies for a while to kill them as opposed to instant enemy death. I'm not sure that this is a game bug though. I will tell you when I get home.

[Pyro1588]

i might try it sometime.
DON'T PM ME ABOUT THIS! I CAN READ THE ******* THREAD!

[Dr_Dos]

That thing looks incredible.

It's not so much a bug, but in the mario games when you're on ice, if you jump straight up when you land you won't slide. Yours did. REGARDLESS IT IS NEATNESS.

[ZzCrook]

This is for everyone like me who is too lazy to download...

[Galladin]

I player the SuperMario MZX for a while at Jauhis' place, and it looked really good. However, it was really slow and stuff...it was incredibly annoying to play it, since Mario was moving so slowly and all.

EDIT: Oh, a new version.

This post has been edited by Galladin: 06 May 2004 - 09:21 AM