[Micah]

Because I'm retarded.

What are the best ways to go about it?

[LogiCow]

char, byte and char_byte counters.

They control the char set data.

Use the vlayer as a place to store your sprites, with the vcoX,Y counter.


See spriter.txt as an example.

: "justentered"
copy block at "('thisx'+1)" "thisy" for 2 by 1 to "$s" 44
set "charset" to "$s"
load char set "&charset&.chr"
load palette "&charset&.pal"

loop start
set "byte" to "('loopcount'%14)"
set "char" to "('loopcount'/14)"
set "vco('loopcount'/14),('loopcount'%14)" to "('char'>31*'char_byte')"
loop for "(256*14-1)"

copy block at 9 4 for 82 by 27 to 94 4
: "l"
set "spr" to 0
wait for 1
load char set "&charset&.chr"
copy block at 9 4 for 82 by 27 to 94 4
set "nchar" to 128

if "spr" < 1 then "l"
set "a" to 0
: "l2"
goto "#sp"
inc "a" by 1
if "a" < "spr" then "l2"
goto "l"

: "#sp"
set "board_x" to "('s&a&_x'/8+85)"

set "x2" to "('s&a&_x'+32%8)"
set "board_y" to "('s&a&_y'/14)"
set "y2" to "('s&a&_y'+28%14)"

if "board_x" < 94 then "#return"
if "board_x" > 174 then "#return"
if "board_y" < 4 then "#return"
if "board_y" > 29 then "#return"

goto "#0"
inc "board_x" by 1
if "x2" != 0 then "#1"
dec "board_x" by 1
inc "board_y" by 1
if "y2" != 0 then "#2"
inc "board_x" by 1
if "y2" != 0 then "#3"
goto "#return"

: "#0"
if "board_char" > 127 then "m0"

set "char" to "nchar"
inc "nchar" by 1

set "byte" to "y2"
loop start
set "char_byte" to "('vco('s&a&_c'),&loopcount&'>>'x2'o'vco&board_char&,('y2'+'loopcount')')"
inc "byte" by 1
loop for "(13-'y2')"
put "('board_color'/16*16+'s&a&_co')" CustomBlock "char" at "board_x" "board_y"

goto "#return"

: "m0"
set "char" to "board_char"
set "byte" to "y2"
loop start
set "char_byte" to "('vco('s&a&_c'),&loopcount&'>>'x2'x'char_byte')"
inc "byte" by 1
loop for "(13-'y2')"
goto "#return"

: "#1"
if "board_char" > 127 then "m1"

set "char" to "nchar"
inc "nchar" by 1

set "byte" to "y2"
loop start
set "char_byte" to "('vco('s&a&_c'),&loopcount&'<<(8-'x2')o'vco&board_char&,('y2'+'loopcount')')"
inc "byte" by 1
loop for "(13-'y2')"
put "('board_color'/16*16+'s&a&_co')" CustomBlock "char" at "board_x" "board_y"

goto "#return"

: "m1"
set "char" to "board_char"
set "byte" to "y2"
loop start
set "char_byte" to "('vco('s&a&_c'),&loopcount&'<<(8-'x2')x'char_byte')"
inc "byte" by 1
loop for "(13-'y2')"
goto "#return"

: "#2"
if "board_char" > 127 then "m2"

set "char" to "nchar"
inc "nchar" by 1

set "byte" to 0
loop start
set "char_byte" to "('vco('s&a&_c'),('loopcount'+14-'y2')'>>'x2'o'vco&board_char&,&loopcount&')"
inc "byte" by 1
loop for "('y2'-1)"
put "('board_color'/16*16+'s&a&_co')" CustomBlock "char" at "board_x" "board_y"

goto "#return"

: "m2"
set "char" to "board_char"
set "byte" to 0
loop start
set "char_byte" to "('vco('s&a&_c'),('loopcount'+14-'y2')'>>'x2'x'char_byte')"
inc "byte" by 1
loop for "('y2'-1)"
goto "#return"

: "#3"
if "x2" = 0 then "#return"
if "board_char" > 127 then "m3"

set "char" to "nchar"
inc "nchar" by 1

set "byte" to 0
loop start
set "char_byte" to "('vco('s&a&_c'),('loopcount'+14-'y2')'<<(8-'x2')o'vco&board_char&,&loopcount&')"
inc "byte" by 1
loop for "('y2'-1)"
put "('board_color'/16*16+'s&a&_co')" CustomBlock "char" at "board_x" "board_y"

goto "#return"

: "m3"
set "char" to "board_char"
set "byte" to 0
loop start
set "char_byte" to "('vco('s&a&_c'),('loopcount'+14-'y2')'<<(8-'x2')x'char_byte')"
inc "byte" by 1
loop for "('y2'-1)"
goto "#return"

However, it is unoptimal and has some flaws. I suggest you only use it as a reference.

[Micah]

I meant like... explain how it works, not paste code.

[Micah]

Ok I've established what the char, byte, and char_byte counters do, and I can move a dot around on the screen, but how would I work collisions? I can set up collisions with customblocks pretty easily, but what about half-chars?

[Koji]

For collision, you have to code that yourself.

Most people just use a distance thing. or checking on a character basis for blocks that would stop a pixel from progressing through the next character... and SOME might want to use a pixel detection algorithm it see if an individual pixel would bloke movement (of course the fastest is checking by static blocks and distances between other bypixel moving things.

Basicly, look up material on entry level 2d game programming and concentrate on collision detection. There are various methods.

[Exophase]

Koji, on Jul 24 2007, 06:31 AM, said:

Most people just use a distance thing.

Yeah for like the three or so people who have really done it.

[Risu2112]

Exophase, on Jul 24 2007, 08:06 AM, said:

Koji, on Jul 24 2007, 06:31 AM, said:

Most people just use a distance thing.

Yeah for like the three or so people who have really done it.

Thankfully for gameplay reasons I never actually needed to figure out collision detection!

[Nedemai]

When I programmed up my pixelperfect thingy I exploited the mzx boards so I could detect where the walls the character wasn't suppost to go through depending on what block was directly infront of the direction the player was going. It was as simple as drawing a customblock instead of a customfloor. To make up the pixels in the image the mzx board contained the whole image of the board including all the extras to make the board work (ie transporting the player to other places etc.)

There are many ways to go about pixel perfectness. other ideas I had included using about 4 or 8 mzx chars that would kind of wrap around so that although the character existed on the mzx board it would still appear pixel perfect. Using char edit a whole row of pixels can be moved either north or south on the screen with ease, but left and right is another issue.

Micah if you have question about this feel free to ask me on irc where I can explain in more detail.

[hob nado]

IMO, MZX is the worst possible game maker for pixel-based motion. I would first start by asking yourself why you hate yourself and want to pound square pegs into round holes =(

[Mr. Apol]

i'm on es with this what the fuck are you guys even talking about

christ go use some builtins

[Dr Lancer-X]

yes and yes. remember, you guys got into MZX because of what you could do with it, not what was severely impractical to do in it. why waste the time?

[CHEZZY]

Exactly correct lancer
But those games by Logicow sure do look sweet...

[Risu2112]

Lancer-X, on Jul 24 2007, 10:49 PM, said:

yes and yes. remember, you guys got into MZX because of what you could do with it, not what was severely impractical to do in it. why waste the time?

Actually, what always appealed to me (and still does) about megazeux was the concept of trying to accomplish a lot with something so limiting.

All things considered with regards to SFmzx development, converting the combat engine to pixel perfect was a HUGE gain for gameplay with such a small amount of time to implement.

[Koji]

pixel perfection isn't a hard engine to impliment if you know how you'd like to work with it, for example, when I make a pixel perfect engine, I like to use characterset data, and I basicly tell the engine what color, what character and where to put it and that seems to work fine. I'll also in some cases (if I want to make a multi char pixel perfect object make a psuedo sprite) I'll program it in such a way that I give the engine the location of the graphic that I want to be moved around pixel perfectly on the board in custom blocks with chars and (usually) all one color, and then the engine reads what character was used and what color it is, and places the chars in reference to the graphic reference area designated.

ANYWAY best way to learn is to find a pixel perfect game and look at how it was implimented, most of the time they really are pretty simple.

[LogiCow]

Pixel perfectness helps your gameplay _so much_ that it is really worth the slight technical difficulties.

To have acceptable gameplay, platformers have to either use pixel perfectness, huge sprites or slow and accurate movement coupled with good level design.

Most 1x1 mzx platformers are much too fast, and that makes jumps on 1x1 platforms really hard. Plus, they tend to have this strange triangular jump that makes jumping look stupid. And, in my opinion, they don't make you jump high enough.



Its code is very straight-forward, and has little to no exception cases, compared to other things such as multi-robot bosses and textured polygons. Those were horrible.

Another problem is the collision detection, which you will be left to do on your own.


I did suggest implementing part of it into megazeux to make it easier.

[nooodl]

Eh, Logi, I think Lancer just said he's not going to do that.

But I like the idea and I'd love to see a pixel-perfect game - doesn't matter if MZX "isn't made for it" - just let Logi do what he wants to, cuz I love his graphic 3D things.

*pastes code in MZX*

EDIT: eh, it doesn't work. Nevermind.

This post has been edited by HappyFoppy: 25 July 2007 - 01:15 PM

[Frobozz]

Logicow said:

Another problem is the collision detection, which you will be left to do on your own.

If you can create a per-pixel engine then collision detection should be simple enough. Not like bounding box/circle is difficult or anything.

[CJA]

LogiCow, on Jul 25 2007, 08:24 AM, said:

Pixel perfectness helps your gameplay _so much_ that it is really worth the slight technical difficulties.

To have acceptable gameplay, platformers have to either use pixel perfectness, huge sprites or slow and accurate movement coupled with good level design.

Most 1x1 mzx platformers are much too fast, and that makes jumps on 1x1 platforms really hard. Plus, they tend to have this strange triangular jump that makes jumping look stupid. And, in my opinion, they don't make you jump high enough.

http://www.digitalmz...showtopic=10960

http://www.digitalmz...showtopic=10636

http://www.digitalmz...?showtopic=9191

There should be a thread about a pixel perfect platformer with comments twice as applauding as these, since pixel perfectness "helps your gameplay _so much_"

[Val]

LogiCow, on Jul 25 2007, 08:24 AM, said:

Most 1x1 mzx platformers are much too fast, and that makes jumps on 1x1 platforms really hard. Plus, they tend to have this strange triangular jump that makes jumping look stupid. And, in my opinion, they don't make you jump high enough.

If people don't want these things happening, that doesn't mean they have to go pixel-perfect or use massive sprites. All they have to do is make a better engine. I know from experience that all of these problems are easily avoided, because I'm making a game that does right now.

[Dr Lancer-X]

LogiCow, on Jul 25 2007, 10:24 PM, said:

Most 1x1 mzx platformers are much too fast, and that makes jumps on 1x1 platforms really hard. Plus, they tend to have this strange triangular jump that makes jumping look stupid. And, in my opinion, they don't make you jump high enough.

Funnily enough, a lot of the jumping sequences in Galatea were quite a bit harder than similar sequences in many 1x1 platformers (Sponkgo's Legendary Journey, CJA and Guy's billion and a half platformers that are all exactly the same, your own Spaceship Crusade etc. etc. along with many other games).

[Exophase]

Lancer-X, on Jul 25 2007, 03:04 PM, said:

LogiCow, on Jul 25 2007, 10:24 PM, said:

Most 1x1 mzx platformers are much too fast, and that makes jumps on 1x1 platforms really hard. Plus, they tend to have this strange triangular jump that makes jumping look stupid. And, in my opinion, they don't make you jump high enough.

Funnily enough, a lot of the jumping sequences in Galatea were quite a bit harder than similar sequences in many 1x1 platformers (Sponkgo's Legendary Journey, CJA and Guy's billion and a half platformers that are all exactly the same, your own Spaceship Crusade etc. etc. along with many other games).

That's exactly what I was thinking.

[Terryn]

Funny, I didn't think so. There was that one tight jump in Galatea, but that's it.

Then again, when I think of tough jumping in MZX games, Adlo and Bocco's game comes to mind, which were downright MEAN.

[Koji]

Really it all does boil down to how the engine is programmed, pixel perfectness is a graphical thing, you don't NEED good graphics to attain the same playability.

[LogiCow]

Happyfoppy: it works if you also include the sprites data loading robot and some robots that call for sprites to be drawn.


The best way to implement pixel movement sprites is to use counters to call for sprites to be drawn.

Basically, you need X, Y, char and color.

then you have a counter keeping track of the amount of sprites on screen.

to add a sprite, just set s&spr&_x, s&spr&_y, s&spr&_c, s&spr&_co and increase spr by one.


Then your drawing robot draws sprites from zero up to spr, and sets spr back to zero for the next cycle.



also, I don't think pixel movement is necessary for platformers, but you need to be careful:

1) Avoid small platforms such as 1x1 and 2x1. If you use them, do so at places where failing the jump will not hurt you, or where they are right next to each other so that it is easy.

2) Avoid enemies that move randomly. Since you have low precision for your attacks, you need to be able to predict the enemy's movements in advance in order to reliably kill them.

3) 1x1 platformers arn't like other platformers, so level design that looks good for regular platformers may not work.

4) You can use speed 2 and program in high delays, so that your character moves slowly, but reacts instantly. I know it sounds strange, but it makes a difference.

5) As a general rule, avoid delays between the time where you hit a button and the your character reacts on the screen. They just ramp up the learning curve, making your game less intuitive to play, and offer little in return. (ex: in Galatea, when you attack, there are two frames where your guy starts swinging his weapon and doesn't actually attack yet. However, it's offset by the fact that you see the guy attacking as soon as you hit the button. And it looks cool.)

6) This is not a console game. This means the player will be using a keyboard, and occasionally, a crappy laptop keyboard. Avoid requiring the player to hold keys to run or to aim diagonally. I highly suggest using z to jump, x to attack. You don't need anything else. If you need to be able to fire in all directions, have the player stop moving when he is attacking, and let him aim with the arrow keys.

7) Things that move faster than one character per cycle need to use special collision detection, otherwise they might skip past things. This shouldn't happen if you keep your game at speed 2.

8) Don't make things move too fast, always give ample reaction time. If the player gets hit, it should be because he made an obvious mistake. You can have specific parts of your game require trial and error, or require memorizing enemy patterns, but players get frustrating quickly. It might seem stupid at first, but the meat of your game should just be breezing through, jumping over slow enemies and dodging easily expected traps.

9) Not everything should have the same size. Even though the chars are 8x14 pixels, you can have enemies smaller than that. Your bosses should really be bigger than 1x1, too. Same with background tiles: there can be small blocks, big blocks, wide blocks, tall blocks...



There are many more tips I could give you about this.

This post has been edited by LogiCow: 25 July 2007 - 11:57 PM

[Old-Sckool]

LogiCow, on Jul 25 2007, 07:29 PM, said:

Happyfoppy: it works if you also include the sprites data loading robot and some robots that call for sprites to be drawn.

The best way to implement pixel movement sprites is to use counters to call for sprites to be drawn.

Basically, you need X, Y, char and color.

then you have a counter keeping track of the amount of sprites on screen.

to add a sprite, just set s&spr&_x, s&spr&_y, s&spr&_c, s&spr&_co and increase spr by one.

Then your drawing robot draws sprites from zero up to spr, and sets spr back to zero for the next cycle.

also, I don't think pixel movement is necessary for platformers, but you need to be careful:
...
4) You can use speed 2 and program in high delays, so that your character moves slowly, but reacts instantly. I know it sounds strange, but it makes a difference.

5) As a general rule, avoid delays between the time where you hit a button and the your character reacts on the screen. They just ramp up the learning curve, making your game less intuitive to play, and offer little in return. (ex: in Galatea, when you attack, there are two frames where your guy starts swinging his weapon and doesn't actually attack yet. However, it's offset by the fact that you see the guy attacking as soon as you hit the button. And it looks cool.)

There are many more tips I could give you about this.

Hmm, this is good stuff. Maybe you help us all code our own Shiny Pixel Perfect Engine Thingy! That speed 2 tip is a really good Idea, I just hava a few questions about it...
Do you use Speed 2 over Speed 1 for a reason (I wonder if it has something to do with timing over different PCs or something.)?
How would you code an engine so that it runs at an apropriate speed? I wonder...

and about no. 5)... Is it me, or do dead enemies hurt you in your latest DOZ platformer? It would be nice for a game to kill off you enemies immediately, so that you could run through the game (almost)

[LogiCow]

Dead enemies do not hurt you.

However, the player's weapon deals a small amount of damage every cycle, rather than one big amount when it hits. That's why double KOs can sometimes happen.


I know it's not the ideal situation, and one big amount is better, but it would require enemy temporary invulnerability when they get hit, which I didn't feel like doing.

This post has been edited by LogiCow: 26 July 2007 - 01:22 AM

[Dr Lancer-X]

The thing about speed 1 is that it's 'unlimited'--speed 1 will go as fast as your computer can go. There's no artificial delay at all (well, there's an artificial delay of 0ms, anyway)

Speed 2, on the other hand, has an artificial delay of 16ms, so it will always be 62.5fps as long as the computer running it is fast enough to reach this. Speed 3 uses 32ms, speed 4 48ms, speed 5 64ms and so on.

As a result, it is best not to use speed 1 for ANYTHING. There is no reason for it, apart from using obscure cycle-ending commands quickly (which are usually unnecessary)

[LogiCow]

Speed 1 is useful for benchmarking, loading and menus where everything reacts instantly.

The main advantage for menus is that the cursor position is refreshed more often, so it feels snappier. But speed 2 is still fine for that.

[Dr Lancer-X]

speed 1 also uses all cycle time, which is totally not what we want (especially because doing that makes my case fans howl like a banshee)

[ajs]

I guess this won't be changed (because historically it was always like this), but ideally speed 1 wouldn't be "no delay" but rather, a very small delay. Even usleep(1) would probably fix the CPU burning artifact. (We aren't using DOS any more, 100% CPU for an interactive application is unacceptable).

BTW, interesting thread. There's a lot more to platformer gameplay than I'd realised.

--ajs.