Seems a long time...

...i am still working on Boinxx (conceptional vise or even coding vise) but world of warcraft and my xbox (Pro Evo Soccer 5) pays my attention...

so i decided that i am touching the code again. last time i have implemented the 1st enemy and it seems to work... so i discussed little bit with TMR of cosine how i can implement the enemies. event driven or time driven and he suggested that i should go for time driven... which seems easier as a first step.

also implemented is a better collision detection and tile determination. in boinxx i'll gonna need 2 approches. the old one which was coded 2 years ago is the one when the player hits the water.... but as some tiles are special tiles and they are "smaller" than the 4x4 ones i need to check the tile map as well and this was a little bit harder than thought in the beginning (think of that you don't check when the ball is high in the sky but when the ball is near the ground...but when the player is near the ground the sprite data is on other position than the player starting position and so on...)

more to come this weekend...

small enemy prototype engine tested

my aim is to bring some emenies to boinxx and i would like to use some dynamic approach to give boinxx a more "professional" look...

so i played around with some approaches and asked one of my mates who is a doctor of physics and he gave me this formular:

* vex=(px-ex)/16
* vey=(py-ey)/16
* ex=ex+vex
* ey=ey+vey

where Vex,y is velocity of the enemy while px,y is the position of the player. ex,y is the enemy position... it took me a little while and with the help of Thomas J. i implemented the code. the difficulty was that we have to deal with signed numbers and to move smooth on screen even with 8.8 fixed point maths. and this is something i managed to understand on 68000 but not on 6502... esp. signed numbers + division. so Thomas - the 2600 maniac behind thrust+ conversion - gave me this:

calc lda px
sec
sbc ex
sta vex
lda px+1
sbc ex+1
cmp #$80
ror @
ror vex
cmp #$80
ror @
ror vex
cmp #$80
ror @
ror vex
cmp #$80
ror @
ror vex
sta vex+1
lda vex
clc
adc ex
sta ex
lda vex+1
adc ex+1
sta ex+1
lda py
sec
sbc ey
sta vey
lda py+1
sbc ey+1
cmp #$80
ror @
ror vey
cmp #$80
ror @
ror vey
cmp #$80
ror @
ror vey
cmp #$80
ror @
ror vey

sta vey+1
lda vey
clc
adc ey
sta ey
lda vey+1
adc ey+1
sta ey+1
rts

and this works perfect...

so stay tuned...

Small Progress

I have planned to release a new version this week. this version of Boinxx will contain some special fx (fog, reverse, big jump, ...) which will be selectable in the debug mode...

so stay tuned...

small update - highscore table

ok... i spend some time with playing around with the possible highscore table. i used Vidol's brilliant G2F logo which fits perfect for a highscore and/or title screen...

what happened last week

ok. small update what happened and what i have done...

i have reorganised the code for more effiecient ram usage. thank god for switching of the OS so i can put a lot of the stuff there like VRAM, font, lookup tables, etc... which is quite handy.

i spend 2 days in figuring out how i can implement a depacker esp. for the level maps. i don't mean the "tile2vram" depacker which generates out of a tile number a 4x4 char tile on screen (which actually saves ram by factor 16!). i tried flashpack but this hasn't worked properly in atari800win4.0 so i was searching for other routines.

as taquart had released numen few years ago i found in the sources a routine called "inflate" which some polish guys at atariarea explained me as a unzip routine... i played 2 days with the sources and used winzip,gnuzip, pucruch etc but it hasnt worked... one of the coder of numen, fox, sent me the c-source code for the deflater which packs data so i can use the inflater for depacking. but i am a business guy and not a coder so i have no c compiler etc installed... so another day went by just trying to compile the packer... but luckily fox sent me in meantime a deflater.exe for pc which i could use... and with this little tool i was able to pack all levels with a ratio from around 50-60% of the orriginal size... so an unpacked level has 1004 bytes and now it takes around 400-600 bytes... quite good.

the good thing about this routine is that it does not uses much varibales or is destructive... i can call the depacker every time i would need to depack data...

so next would be to pack the MPT music files and depack them while runtime... this took me again several hours as the MPT format is a quite native format which must be compiled and saved to a special memory location. so the 1st tests failed simply because i had moved the buffer around but haven't compiled the msx to this new buffer adress...

further i have started with a new level tile set (the missing "rock" one) and with the highscore module which will be depacked by runtime as well...

i like the depacker as i can easily tell the routine take packed data from there and depack it to this adress...so i can pack the highscore module quite heavy and depack it after game over... as it contains one of the g2f graphics it works quite well... (unpacked 7kb, packed 1,7kb!)

so... now back to my Sony PSP...

just got 2 new levels by vidol

just recieved new levels by vidol...

he is still using gfx set 1 but we have 3 others we can use:

Boinxx Logo by dely

Vidol's brilliant WIP Logo