Asking for permission...

contra-sh · 2012-03-04 7:09:31 am

Hi,

I have seen a nice sprite palette in the ti83 sprite page about an unreleased game.
I'm wondering if you could grant me to use your work on megaman sprites.
Of course I will give credits to you in the final game...

Thanks you by advance.

Dwedit · 2012-03-04 9:30:08 am

Go ahead and use them.

contra-sh · 2012-03-04 10:03:20 am

Thank you very much. These sprites are really incredible :)

I have already converted some of them to z80 asm format.
Here some very early screenies :

What do you think about it ?
I use 3 graylevels because as you said, 4 blurs too much :)

I have some questions, I would love to have your opinion/help if you can.

I have some trouble to do smooth scrolling (because I need to know what's the 13th sprite on the right and the -1th sprite on the left)
And I have some other trouble to put the player on the background (because I use xor sprites routines).
How do you handle jumps and collision in bubble bobble?
Yes this is open source I know, I've already studied some of your projects :)
Which tool do you use to convert your sprite palette to z80 asm txt files (I use gimp to cut each sprite then save it to pcx then use sprmaker but I waste a lot of time doing that)

Dwedit · 2012-03-04 11:05:13 am

The serious problem with TI83s is how horrible the motion blur is on the LCD screen. Smooth scrolling ends up looking bad, like gray streaks. I was once working on a Dragon Warrior 2 test program with smooth scrolling and grayscale, so I was appalled at how bad it looked on a real TI83.
You can download the DW2 test game here.

To do a fast, smooth-scrolling background display engine, I looked to CrashMan's code for example. Here's how he does it:
Vertical arrangement for graphics memory instead of horizontal (this changes everything, don't use graphics drawing code not designed for this)
Pre-bitshifted tiles in a buffer somewhere, left halves and right halves. (right half should be blank if pixel X offset is 0)
When you render the tilemap, draw the left half of current tile, then right half of the next tile.
Go down, keep drawing tile pieces...
He also made it output the old byte to the LCD screen, so it's a combination FastCopy / Tile map renderer.

But CrashMan's code is a little tricky to set up, since it uses a vertical graphics memory orientation (next byte takes you down, not right). It also wants certain things to be page aligned in memory so it can use the 8-bit instructions instead of 16-bit instructions.

For game logic stuff, when you want to handle collisions with a tilemap background, what you do is a couple of "pixel hit tests". That's where you truncate X and Y to X/8 and Y/8, then look at what tile is on the map there.

There are certain points that should be hit-tested when moving around. Number of points depends on how big the sprite is. If the sprite is the same size as a background tile, there are two points. If the sprite is as big as up to 2 background tiles, there are three points.

You hit test places so you know whether or not the character will move into a wall.
When moving up, hit test the points on the top part of the character. Like above the upper-left corner, and above the upper-right corner. For big sprites, there's also a point in the top-middle.
When moving right, you test the points to the right of the upper-right and lower-right corner. For big sprites, there's also a point in the right-middle.
And so on.
It's common to make the hit detection points a little bit inside the character, so they can get a little closer to walls. But for the lower points, you don't want the sprite sunken in to the floor, so you keep those test points at the bottom of the sprite.

For sprite-to-sprite collisions, you test if the two sprites are overlapping each other.
You have your X coordinate, and the other X coordinate, and the two widths of the sprites
They overlap if sprite1 is to the left within range of sprite2, or sprite2 is to the left within range of sprite1.
W2 + X2 - 1 >= X1
AND X1 + W1 - 1 >= X2
a little algebra...
X1 <= X2 + W2 - 1 AND X1 >= X2 - W1 + 1

Repeat for Y and Height.

For converting graphics, I used my own conversion software. All the sprites and stuff were drawn in Tile Layer into a big binary file, sort of like how you make or hack graphics for a NES game. Then I used a program to generate Z80 code for the graphics. I never used any "real" graphics formats like bmp, png, or pcx, only .CHR files like when you rom hack .NES games.
Since Tile Layer doesn't work on Windows 2000 or above, YY-CHR is a good replacement for that program.

Got more questions? Ask away.

contra-sh · 2012-03-05 6:04:07 am

Thank you very much for your help.

I've done a first part of collision checking (the gravity) and I've added 2 new sprites (megaman jumping).
I have used the method with truncated x and y to aligned values then I compare it to tilemap.

Here a first result :

I don't know CHR format used by your converter. Did you programs firstly for nes before calc?

I will have a look to your dw games as soon as possible. Do you use interrupt based grayscale?
Which lib do you use? Your own?
Do you use xor routines to draw sprites or masked sprite?
Even with a lot of adjustements, grayscale + smooth scrolling seems not a good idea with TI83, I think I will keep my sprite 8x8 scrolliing because it's working fine and it's nice.

I'm currently working on this game so no questions for the moment, but I will ask a lot of questions soon I think :)

And one more time, thank you !

EDIT: Some progress (collision checking is done) :)

Here the screenie :

And the code (which is basically a lot of tests) :

CHECK_COLLISION_LEFT:
; Tester a gauche (partie haute)
ld a, (xcoord)
sub 8
call DIVIDE_A_BY_EIGHT
ld e, a
ld a, (ycoord)
call DIVIDE_A_BY_EIGHT
ld c, a
call FIELD_GET
cp 2
jp p, ccl_touche_un_mur
; Tester a gauche (partie centrale)
ld a, (xcoord)
sub 8
call DIVIDE_A_BY_EIGHT
ld e, a
ld a, (ycoord)
add a, 7
call DIVIDE_A_BY_EIGHT
ld c, a
call FIELD_GET
cp 2
jp p, ccl_touche_un_mur
; Tester a gauche (partie basse)
ld a, (xcoord)
sub 8
call DIVIDE_A_BY_EIGHT
ld e, a
ld a, (ycoord)
add a, 15
call DIVIDE_A_BY_EIGHT
ld c, a
call FIELD_GET
cp 2
jp p, ccl_touche_un_mur
ccl_ne_touche_rien:
ld a, 1
ret
ccl_touche_un_mur:
ld a, 0
ret
CHECK_COLLISION_RIGHT:
; Tester a droite (partie haute)
ld a, (xcoord)
add a, 16
call DIVIDE_A_BY_EIGHT
ld e, a
ld a, (ycoord)
call DIVIDE_A_BY_EIGHT
ld c, a
call FIELD_GET
cp 2
jp p, ccr_touche_un_mur
; Tester a droite (partie centrale)
ld a, (xcoord)
add a, 16
call DIVIDE_A_BY_EIGHT
ld e, a
ld a, (ycoord)
add a, 8
call DIVIDE_A_BY_EIGHT
ld c, a
call FIELD_GET
cp 2
jp p, ccr_touche_un_mur

; Tester a droite (partie basse)
ld a, (xcoord)
add a, 16
call DIVIDE_A_BY_EIGHT
ld e, a
ld a, (ycoord)
add a, 15
call DIVIDE_A_BY_EIGHT
ld c, a
call FIELD_GET
cp 2
jp p, ccr_touche_un_mur
ccr_ne_touche_rien:
ld a, 1
ret
ccr_touche_un_mur:
ld a, 0
ret

PROTECT_ROOF:
; Tester en haut a gauche
ld a, (xcoord)
call DIVIDE_A_BY_EIGHT
ld e, a
ld a, (ycoord)
call DIVIDE_A_BY_EIGHT
ld c, a
call FIELD_GET
cp 2
jp p, pw_touche_un_mur
; Tester en haut a droite
ld a, (xcoord)
add a, 8
call DIVIDE_A_BY_EIGHT
ld e, a
ld a, (ycoord)
call DIVIDE_A_BY_EIGHT
ld c, a
call FIELD_GET
cp 2
jp p, pw_touche_un_mur

pw_ne_touche_rien:
ld a, 1
ret
pw_touche_un_mur:
ld a, (oldxcoord)
ld (xcoord), a
ld a, (oldycoord)
ld (ycoord), a
ld a, 0
ret

GRAVITY:
ld a, (xcoord)
call DIVIDE_A_BY_EIGHT
ld e, a
ld a, (ycoord)
add a, 16 ; Hauteur
call DIVIDE_A_BY_EIGHT
ld c, a
call FIELD_GET
cp 2
jp p, g_touche_le_sol

ld a, (xcoord)
add a, 8
call DIVIDE_A_BY_EIGHT
ld e, a
ld a, (ycoord)
add a, 16
call DIVIDE_A_BY_EIGHT
ld c, a
call FIELD_GET
cp 2
jp p, g_touche_le_sol
g_nul_ne_peut_echapper_a_la_gravite:
ld hl, ycoord
ld a, (hl)
add a, 1
ld (hl), a
ld a, 1
ret
g_touche_le_sol:
ld a, 0
ret

EDIT 2 : Now There's vertical scrolling (down only in fact)
Here's the proof :

I think it's pretty cool :)

Last edited by contra-sh (2012-03-05 8:24:33 am)

Dwedit · 2012-03-07 12:45:53 pm

Sorry for a late reply....

Motion of sprites is traditionally done with Position and Velocity, and fractional numbers for each value.
You add X and Y Velocity to Position every frame, and see if it has hit a wall. When you hit a wall, reset velocity in that direction to zero.
When you move left or right, you add to velocity until you reach a maximum speed.
Gravity constantly increases Y velocity in the downward direction.
When you jump, you set a strong initial Y velocity upward. To make jumps depend on how long you hit the Jump button, increase the Y velocity slightly every frame as long as you are in the initial ascent of the jump.
Physics note: when you change velocity, that's called Acceleration. But you don't need to keep separate "acceleration" variables or anything like that, adding to and subtracting from velocity is good enough.

Megaman however does not use X velocity, instead it uses fixed speed movement in the X direction. Y direction still uses velocity.
Megaman also has a timer tick down a few frames between you hitting Left/Right and starting movement.

In order to do physics the right way, you need fractional numbers. This is where Fixed Point Math comes into play.
Short explanation of Fixed Point Math:
You know what an integer is.
"Fixed Point" is where you have a convention where you divide the number by something whenever you want its true value (when you "display it").
So you could have a convention where you always divide a number by 16 before you display it. ("Display it" meaning use it as a coordinate for drawing a sprite for example) So 32 would actually be 2.0. When you do things this way, you can add "1/16" (really 1) to "2.0" (which is really 32).
Usually you use whole bytes as your fractional part. So you'd have 3 bytes for coordinates. A 16-bit value for the integer part (0-65535), and an 8-bit value for the fractional part.
If you use 8 bits for your fractional part, 0.5 = 128/256, 0.25 = 64/256, .125 = 32/256, etc. You can't represent numbers like 0.1 though, there's not enough precision, you'd need to round it to 26/256.

Use fixed point for both position and velocity.

One way to simplify programming a game is to use a "Camera Position". So the game can always redraw everything based on where the Camera is located, just subtract Camera coordintes from Object coordinates when you draw things. Yes, things will be off the screen. Yes, you need more that 8-bit numbers to represent coordinates, I suggest 24-bit fixed point numbers, where the high 16 bits are the integer part, so you can simply discard the fractional byte when you draw stuff.

Now some suggestions for your game:

I think you have a neat animation test program, but I don't see making that into a game without getting rid of several issues.

Moving 8 pixels horizontally per frame really sucks. I'd never play a game like that.

I'd suggest adding "catch-up" style scrolling, where when you move too far to the right, the camera advances to the right by a lot. Sort of like Zelda-style scrolling, but you don't need to go all the way to the edge first.

When you have scrolling, you need to be able to "wake up" enemies that have come onto the screen, then remember that a particular enemy has been spawned or killed, so it doesn't generate enemies every time you scroll it on. Then when it's far enough from the screen, destroy it, but make it come back the next time it's scrolled on.

contra-sh · 2012-03-08 10:47:37 am

Ok.

Thank you very much for the reply. That's really very interesting :)

Firstly the things I've done since the last post :
- Scrolling up.
- Bullet handling.

Here's a little screenie :

Yes there's some bugs (megaman sometimes runs during falling, and jump is not implemented)

There's still some troubles for collision checking with non aligned sprites position.

You're right, I dislike the 8x8 scrolling, but I'm not a great programmer and smooth scrolling seems too hard to do for the moment.

I didn't noticed that megaman uses velocity for the jump in fact, and thank you for this great explanation :)
I haven't even done a jump handling (player can jump as he want, even without being on the floor, so it's more flying than jumping :p)
I have already heard about fixed point (in order to do zoom in/ zoom out) and I think I will use it as soon I feel able to do that :)

I suggest 24-bit fixed point numbers, where the high 16 bits are the integer part, so you can simply discard the fractional byte when you draw stuff.

Waoo I love this idea ! Yes I will definitely use it in the future.

About camera position...
I don't use x and y coords to do that, but a shift value and a depth value (so x and y are only 8 bits but shift and depth are 16bits).

I have a map like this :

map1:
.db 2, 2, 2, 2, 2, 2,2, 2, 2,2, 2, 2,2, 2, 2,2, 2, 2,2, 2, 2,2, 2, 2,2, 2, 2,2, 2, 2,
max_shift:
.db 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2,
.db 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2,
.db 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2,
.db 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2,
.db 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2,
.db 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2,
.db 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2,
max_depth:

And I have a small field 12 * 8 which is really printed to the screen :

field:
.db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
.db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
.db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
.db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
.db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
.db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
.db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
.db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

And each (8x8) scroll I copy the useful portion of the map into the field matrix :

COPY_MAP_INTO_FIELD:
ld hl, map - (max_shift - map)
ld a, (profondeur)
ld b, a
aller_profond:
ld de, max_shift - map
add hl, de
djnz aller_profond

ld a, (decalage)
ld d, 0
ld e, a
add hl, de
ld de, field
ld b, 8

copy_it:
push bc
ld bc, 12
ldir
push de
ld de, max_shift - map - 12
add hl, de
pop de
pop bc
djnz copy_it
ret

So if I put some enemies on the map matrix, I could save if they are alive or not.
And I can animate they only if they are in the useful board (field).

For bullets I use a separate matrix (12 *8).
So I can add it separately from the useful matrix which is moving often but I'm not sure if it's a good method because when megaman falls, bullets falls too ...
As you can see scrolling is slightly different (you can move and scrolls, sometimes only move, sometimes both).
What I want to do is :
The player move in a small window in the screen, when he leaves this window, then scroll (if possible).
Disable scroll for bosses.

About the matrix :
Right bullets are 2 and left bullets are 1 (0 is no bullet).
And I shift bullets to the borders right (if 2) and left (if 1).

I don't really like the catchup style scrolling. In fact I like it (zelda 1 on nes) because it's old school, but I think people is most impressed by 8x8 scrolling or smooth scrolling. What do you think?

Enemies will be an hard task to do... (Animated enemies)

And yes, I already have some issues (collision checking) :)

Thank you very much, you're really a great help.

chickendude · 2012-05-06 10:12:45 am

Hey Dwedit! I just wanted to say thank you for writing out everything, especially the bits on physics and using fractions in z80. It's something i've never done before and something i probably never would have thought of! The game is really starting to take shape :)

Last edited by chickendude (2012-05-06 10:16:12 am)

chickendude · 2012-11-06 11:09:18 pm

Here are some more recent screenshots:
Showing some enemies:
zEJ5?.gif
We've also started working on the bosses, here's a couple:
Gutsman:
hUyo
Woodman:
318K

Dwedit · 2012-11-07 1:53:52 am

Holy crap! Looking awesome!

chickendude · 2012-11-07 7:13:35 am

Thanks! We just finished the last of the 8 main bosses, the only major things left now are adding in items, using the boss weapons after beating a boss, and the final stage/Dr. Wily. :)

Dwedit's Board

Announcement

#1 2012-03-04 7:09:31 am

Asking for permission...

#2 2012-03-04 9:30:08 am

Re: Asking for permission...

#3 2012-03-04 10:03:20 am

Re: Asking for permission...

#4 2012-03-04 11:05:13 am

Re: Asking for permission...

#5 2012-03-05 6:04:07 am

Re: Asking for permission...

#6 2012-03-07 12:45:53 pm

Re: Asking for permission...

#7 2012-03-08 10:47:37 am

Re: Asking for permission...

#8 2012-05-06 10:12:45 am

Re: Asking for permission...

#9 2012-11-06 11:09:18 pm

Re: Asking for permission...

#10 2012-11-07 1:53:52 am

Re: Asking for permission...

#11 2012-11-07 7:13:35 am

Re: Asking for permission...

Board footer