XDC engine development thread (alpha version)

Everything about the various Boulder Dash tools, and other stuff created by the fans.

Moderator: Admin

Post Reply
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

XDC engine development thread (alpha version)

Post by LogicDeLuxe »

EDIT: thread renamed, as the engine is alpha now. The tables in the initial post here remain drafts, though. In the current version, quite a lot is re organized, and probably still will during development. I'll keep posting new alpha versions occasionally.

Here is a first draft of what I might do. My next engine will come with a converter which reads BDCFF and convert them into a memory saving C64 format.
- There will be the long demanded level feature.
- cavesize will probably remain constant for performance reasons. Intermissions may be 40x22 or 20x12 in the BDCFF file.
- All is subject to change, as this really is just an initial draft.

Code: Select all

Each cave will begin with a standardized structure of mandatory parameters:
Offset (hex), size (dec), meaning:
0000  10  time to solve for each level
000a  10  diamonds needed for each level
0014   1  diamond value
0015   1  bonus diamond value
0016  ln  border color (c64 only)
0016  hn  background color
0017  ln  color 1
0017  hn  color 2
0018  ln  color 3
0018  hn  amoeba color (atari and C64dtv only)
0019   1  bit 2=activeguyscan
          bit 3=activeguyisfirst
          bit 4=instantlife
          bit 5=rewardlife
          bit 6=is intermission
          bit 7=no scroll
001a   5  Frametime ms +50 for each frame
001f      object codes

object codes:
00-7f=regular object code or optional cave parameter
81-9e=level(s) on which the following instruction is executed (bit 0-4=level bits), not supported for variable length objects
ff=level end+animation bits
animations:
bit 0=firefly
bit 1=butterfly
bit 2=amoeba
bit 3=slime
bit 4=biter
bit 5=bubble
bit 6=amoeba_color (atari only)

00: random fill generic
  param byte 1: initial fill
  param byte 2: top left row
  param byte 3: top left column
  param byte 4: height-1
  param byte 5: width-1
  param byte 6: probability 1
  param byte 7: probability 2
  param byte 8: probability 3
  param byte 9: probability 4
  param byte 10: element 1
  param byte 11: element 2
  param byte 12: element 3
  param byte 13: element 4
  param byte 14: element to draw on ($ff = all)
  param byte 15-19: seed for each level

01: random fill economy
  param byte 1: probability 1
  param byte 2: probability 2
  param byte 3: probability 3
  param byte 4: probability 4
  param byte 5: element 1
  param byte 6: element 2
  param byte 7: element 3
  param byte 8: element 4
  param byte 9-13: seed for each level
 
02: draw a line of an object
  param byte 1: object to draw
  param byte 2: begin row
  param byte 3: begin column
  param byte 4: end row
  param byte 5: end column
 
03: draw a single object
  param byte 1: object to draw
  param byte 2: row
  param byte 3: column

04: draw a rectangle of an object, filled with a second object
  param byte 1: object to draw
  param byte 2: top left row
  param byte 3: top left column
  param byte 4: height-1
  param byte 5: width-1
  param byte 6: object to fill with ($ff=don't draw)


Planned after the first alpha release:
  
##: draw a raster pattern of an object
  param byte 1: object to draw
  param byte 2: top left row
  param byte 3: top left column
  param byte 4: amount of rows
  param byte 5: amount of columns
  param byte 6: distance between rows
  param byte 7: distance between columns

##: draw a map of an object (bf=escape byte, value, count)
  param byte 1: object to draw
  param byte 2: top left row
  param byte 3: top left column
  param byte 4: amount of rows (must be mod 8 to keep the code simple)
  param byte 5: amount of columns
  param byte 6 onwards: the map description with LSBs drawn first

##: add an object relative to another (economy)
  param byte 1: existing object
  param byte 2: object to draw
  param byte 3: distance to the right; if the end of the row is reached, the next row is used.
  
##: add an object relative to another (generic)
  Distances are singed bytes.
  param byte 1: existing object
  param byte 2: object to draw
  param byte 3: object to replace
  param byte 4: distance x
  param byte 5: distance y

##: true random fill
  param byte 1: top left row
  param byte 2: top left column
  param byte 3: amount of rows
  param byte 4: amount of columns
  param byte 5: element 1
  param byte 6: probability 1
  param byte 7: element 2
  param byte 8: probability 2
  param byte 9: element 3
  param byte 10: probability 3
  param byte 11: element 4
  param byte 12: probability 4
  param byte 13: element to overdraw ($ff = all)
 
##: maze with seed
  param byte 1: top left row
  param byte 2: top left column
  param byte 3: amount of rows
  param byte 4: amount of columns
  param byte 5: wall thickness
  param byte 6: path thickness
  param byte 7: wall element (ff=don't draw)
  param byte 8: path element (ff=don't draw)
  param byte 9: type 0=perfect, 1=braid, 2=unicursal (not sure about those, yet)
  param byte 10-14: seed for each level

##: true random maze
  param byte 1: top left row
  param byte 2: top left column
  param byte 3: amount of rows
  param byte 4: amount of columns
  param byte 5: wall thickness
  param byte 6: path thickness
  param byte 7: wall element (ff=don't draw)
  param byte 8: path element (ff=don't draw)
  param byte 9: type 0=perfect, 1=braid, 2=unicursal, 3=cavern, 4=crack (not sure about the types 1 to 4, yet)

##: enable diagonal movements
  no parameters
 
##: disable diagonal movements
  no parameters
 
##: amoeba
  param byte 1,2:
    bit 0-11=time
    bit   14=waits for hatching
    bit   15=timer starts immediately
  param byte 3,4: max size
  param byte 5: slow grow speed
  param byte 6: fast grow speed
 
##: amoeba2
  param byte 1,2:
    bit 0-11=time
    bit   13=explode when amoeba 1 is touched
    bit   14=waits for hatching
    bit   15=timer starts immediately
  param byte 3,4: max size
  param byte 5: slow grow speed
  param byte 6: fast grow speed
 
##: magic wall
  param byte 1, 2:
    bit 0-11=time
    bit   13=emulates bd1
    bit   14=converts amoeba
    bit   15=waits for hatching

##: enemydirection
  param byte 1, 2:
    bit 0-11=time
    bit   13=enable autochanges
    bit   14=change at hatching
    bit   15=start backwards

##: biter properties
  param byte 1: delay (0)
  param byte 2: element to eat (dirt)

##: bladder properties
  param byte 1: collides with (Mrs. Rockford)
 
##: BonusTime
  param byte 1: time 

##: BorderProperties
  param byte 1:
    bit 0=scan on border (true)
    bit 6=effects on border (true)
    bit 7=wraparound (true)
    (using Prof. Knibbles wrapcode, imperfect and with lineshifting for performance reasons)
   
##: DummyProperties
  param byte 1:
    bit 0=diamondcollector (false)
    bit 6=penalty (false)
    bit 7=destructable (true)
   
##: Effect
  param byte 1: element to replace
  param byte 2: replacement element
 
##: use short explosions
  no parameters

##: use long explosions
  no parameters

##: penalty time
  param byte 1: time
 
##: SlimePermeabilityC64
  param byte 1: bit pattern
  param byte 2: seed (only effective if used after all maze and random placements)

##: HatchingDelay
  param byte 1: framecount (0 means using the traditional 2-seconds-delay)

##: draw a RLE compressed PLCK map (bf=escape byte, value, count)
  param byte 1: top left row
  param byte 2: top left column
  param byte 3: amount of rows (must be mod 2 to keep the code simple)
  param byte 4: amount of columns
  param byte 5 onwards: the map description

##: draw a RLE compressed CrLi map (bf=escape byte, value, count)
  param byte 1: top left row
  param byte 2: top left column
  param byte 3: amount of rows
  param byte 4: amount of columns
  param byte 5 onwards: the map description

##: Floodfill (not sure about implementing this, as this really might slow on a C64)
  param byte 1: row
  param byte 2: column
  param byte 3: object to draw
  param byte 4: object to replace (ff=pick object at row/column)
 
##: Boundaryfill (not sure about implementing this, as this really might slow on a C64)
  param byte 1: row
  param byte 2: column
  param byte 3: object to draw
  param byte 4: boundary object

  
All unspecified bits are reserved for future extension and should be set to 0.
No promise for an Atari version, though.
I might add some more tweaks to make it most compatible to BD1, BD2, PLCK, 1stB and CrLi.
So what do you think? Any suggestions? Though keep in mind the limited capabilities of a C64.
Last edited by LogicDeLuxe on Sun Oct 19, 2008 12:25 pm, edited 5 times in total.
User avatar
Arno
Site Admin
Posts: 2826
Joined: Sat Mar 17, 2007 2:26 pm
Location: netherlands
Contact:

Post by Arno »

Great!!! :D
One question about this part:

Code: Select all

0021   1  bit 4=instantlife (intermission only)
          bit 5=rewardlife (intermission only)
          bit 6=is intermission
          bit 7=no scroll
Does the "instantlife" switch mean that moving to the next cave after faillure can be switched on/off for intermissions?

It is my wish for years to create a game with only intermissions, but without:
- getting a bonus life at the start;
- moving to the next screen after faillure.

If I got it right this will be possible with your new engine ?!? :o
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

Arno wrote:It is my wish for years to create a game with only intermissions, but without:
- getting a bonus life at the start;
- moving to the next screen after faillure.

If I got it right this will be possible with your new engine ?!? :o
This is a more general setup for what we used to have in engines before. The equivalent for previous engines would be
BD1, BD2, PLCK, 1stB, CrLi Cave: instantlife=false, rewardlife=false, is intermission=false, no scroll=false
BD1, BD2, PLCK Intermission: instantlife=true, rewardlife=false, is intermission=true, no scroll=true
1stB, CrLi Intermission: instantlife=false, rewardlife=true, is intermission=true, no scroll=true

Not exactly sure about your question. "moving to the next screen after faillure" (instead of loosing one life) is what the "is intermission"-bit does. So if you don't want this, why bother making it an intermission in the first place?
Eventhough I wrote "(intermission only)", it should be no problem to allow those in caves as well.
User avatar
Arno
Site Admin
Posts: 2826
Joined: Sat Mar 17, 2007 2:26 pm
Location: netherlands
Contact:

Post by Arno »

LogicDeLuxe wrote:Not exactly sure about your question. "moving to the next screen after faillure" (instead of loosing one life) is what the "is intermission"-bit does. So if you don't want this, why bother making it an intermission in the first place?
For my purpose, an alternative would be to make a cave with scrolling=false. But there's a slight difference. In intermissions (at least in the PLCK engine) the right border becomes visible when Rockford hatches, like this:

Before hatching:
Image

After hatching:
Image

In caves (with scrolling) this does not happen. I don't like to have the right border invisible. Neither do I like to make each level one column smaller. The question is thus, which switch makes this "shift" happening? It would be great if the scrolling-switch could control this. If that is the case, the following settings should work for me:

instantlife = false;
rewardlife = false;
is intermission = false;
no scroll = true.
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

Arno wrote:In caves (with scrolling) this does not happen. I don't like to have the right border invisible. Neither do I like to make each level one column smaller. The question is thus, which switch makes this "shift" happening? It would be great if the scrolling-switch could control this.
Exactly. The no scroll bit will enable the 20 column view, as this is in fact directly related to the scroll routine.
User avatar
Arno
Site Admin
Posts: 2826
Joined: Sat Mar 17, 2007 2:26 pm
Location: netherlands
Contact:

Post by Arno »

LogicDeLuxe wrote:Exactly. The no scroll bit will enable the 20 column view, as this is in fact directly related to the scroll routine.
Great! Thanx! :D
Another question. Is this engine to be used within your final CLCK release? Will there be a packer created, or is it only possible to make games by converting from BDCFF?
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

Arno wrote:Is this engine to be used within your final CLCK release? Will there be a packer created, or is it only possible to make games by converting from BDCFF?
It will be a separate release from CLCK as its purpose is slightly different. While the Crazy Light Tools are made to be a completely standalone C64 tool kit, the new engine can be considered more like cross development with the C64 as the target platform.

The tools will be very similar to the Crazy Light Tools, except there will be a BDCFF compiler instead of the Construction Kit. Chances are good, that the graphics, title screen and intro screen remain compatible, so that those tools can stay the same, thus no need to rewrite them.
GDash is your tool to design the caves, as long as you keep an eye on the engine's restrictions. Or alternatively, you can try writing caves by hand with a plain text editor.
User avatar
Sendy
Member
Posts: 186
Joined: Sun Jun 17, 2007 10:33 pm
Location: Square Wave Heaven
Contact:

Post by Sendy »

Ooh, maybe SendyDash 8 or so will be a level-based game, I've always wanted to rock it oldschool like that. I imagine finding the different random seeds can be fun.
Watcher Kitty is always watching...
User avatar
Arno
Site Admin
Posts: 2826
Joined: Sat Mar 17, 2007 2:26 pm
Location: netherlands
Contact:

Re: First draft of my upcoming engine

Post by Arno »

Hi Logic! I was still wondering about the following...
LogicDeLuxe wrote:My next engine will come with a converter which reads BDCFF and convert them into a memory saving C64 format.
This converter reads the caves from a BDCFF, but how will we deliver a title screen, intro text, graphics-set, etc.?

And is it possible to use BDCFF with mapped caves (probably without level feature), or is it only possible to generate the caves procedurably?
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Re: First draft of my upcoming engine

Post by LogicDeLuxe »

Arno wrote:This converter reads the caves from a BDCFF, but how will we deliver a title screen, intro text, graphics-set, etc.?
The same tools as in CrLi. The graphics editor is on the todo list, too.
And is it possible to use BDCFF with mapped caves (probably without level feature), or is it only possible to generate the caves procedurably?
I did not decided on this one, yet. Do you think, that would be a useful feature? If yes, why?

If it is just for the sake of bringing back some caves to the C64, their original engine would be probably the best choice. I will write an universal converter someday which can do this, as I suggested here: http://www.boulder-dash.nl/forum/viewtopic.php?t=94
User avatar
Arno
Site Admin
Posts: 2826
Joined: Sat Mar 17, 2007 2:26 pm
Location: netherlands
Contact:

Re: First draft of my upcoming engine

Post by Arno »

LogicDeLuxe wrote:Do you think, that would be a useful feature? If yes, why?
For me it would be very useful! I already have a large set of PLCK intermissions that I'd like to release as 12x20 caves (upper left corner) in a few games, as I explained above. With your new engine this becomes possible, as the parameters 'instantlife', 'rewardlife', 'is_intermission' and 'no_scroll' can be adjusted independently. I simply have to rebuild the maps in GDash, or directly in BDCFF. :) Without the feature I'm restricted to use object codes, random seeds, etc..

A good alternative would be if the switch "no_scroll" is available in the final CLCK. Afaik, this is not the case yet.
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

A revised version of my proposal for my upcoming engines are online.
This is not the complete list of BDCFF keywords, but it reflects mostly what is required in my cross development C64 engine and what is done in Gdash already for the most part.
Also very important, the cave object instructions, which seems to be the only up to date reference.
The coloring has different meanings now in regard to what can be expected in my upcoming engines, which is described at the beginning of that document.
http://www.gratissaugen.de/erbsen/bdcff.html
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

I thought of adding even demo support. This would be done similar to those in Doom, ie. they would play in sequence.
To keep them small, which sure is important on a C64, I though of storing a random seed in the demo file and use the pseudo random generator for amoeba and boulder pushing etc., so those don't have to be stored in the demo file (which is also the way Doom does it).

So for what remains, how could that be kept small efficiently? Code for interpreting must be kept simple as well, of course.

The joystick poll delivers 5 significant bits. I though of a translation table compressing those to 4 using only the possible and useful ones. Firebutton with no direction is dispensable, since its only use is to abord the cave when you're dead. A button combination with a direction can be used to replace such an ending trigger.

Joystick (up, down, left, right, button) diagonal movements included:
00000=0
00001=1
00010=2
00100=3
00101=4
00110=5
01000=6
01001=7
01010=8
10001=9
10010=a
10100=b
10101=c
10110=d
11000=e
11001=f
11010
Too bad, one to much.
If we dismiss diagonal movements, we have:
00000=0
00001=1
00010=2
00100=3
01000=4
10001=5
10010=6
10100=7
11000=8
We sure could use 4 bytes for a counter, but unfortunately, we are again off by only one to fit the joystick value in only 3 bits. Also, we would sacrifice demo capability for caves with diagonal movements. Eventhough it is rarely used, it is not exactly a good idea.

One solution, I though of, would be some kind of huffman table, which would take a mere table of 32 bytes.
The engine would lookup the lower 5 bits in that tables. the lower five bits will tell the joystick value, the other 3 bits tell how many bits are used for the counter. The trick is, that the same code is used with bit 4 set and unset for values with 4 bit counters and also even bit 3 with 5 bit counters, so those bits can be used as counter bits at the same time.
So we would get something like this

byte in demo data=bits available for the counter, joystick value in table:
xxx00000=101 00000 (5, still)
xxx00001=100 00001 (4, up)
xxx00010=100 00010 (4, down)
xxx00011=101 00100 (5, left)
xxx00100=011 00101 (3, up and left)
xxx00101=011 00110 (3, down and left)
xxx00110=101 01000 (5, right)
xxx00111=011 01001 (3, up and right)
xxx01000=101 00000 (5, still)
xxx01001=011 01010 (3, down and right)
xxx01010=011 10001 (3, up and button)
xxx01011=101 00100 (5, left)
xxx01100=100 10100 (4, left and button)
xxx01101=100 11000 (4, right and button)
xxx01110=101 01000 (5, right)
xxx01111=011 10101 (3, up, left and button)
xxx10000=101 00000 (5, still)
xxx10001=100 00001 (4, up)
xxx10010=100 00010 (4, down)
xxx10011=101 00100 (5, left)
xxx10100=011 11001 (3, up, right and button)
xxx10101=011 11010 (3, down, right and button)
xxx10110=101 01000 (5, right)
xxx10111=011 10110 (3, down, left and button)
xxx11000=101 00000 (5, still)
xxx11001=011 00000 (3, suicide key pressed, the direction does not matter, since Rockford explodes and is therefor unable to move)
xxx11010=011 10010 (3, down and button)
xxx11011=101 00100 (5, left)
xxx11100=100 10100 (4, left and button)
xxx11101=100 11000 (4, right and button)
xxx11110=101 01000 (5, right)
xxx11111=111 11111 (x, end of demo data)

The counter is increased by 1 during evaluating, since 0 makes no sense here, so we have a maximum of 8, 16 and 32 steps per byte.

The header of the demo file would consist of
offset=usage (type)
$0000=cave number (byte)
$0001=level number (byte)
$0002=random seed for amoeba (byte)
$0003=random seed for pushing boulders (byte)
$0004=random seed for random mazes (byte)
$0005=random seed for random placements (byte)

Maybe $0002-$0005 could be combined into just one instance, which would not only save 3 bytes here, but also several lines of code. Or I could even use the one and only existing one, but this would influence the predictable slime. Do you thing this is a considerable trade off in order to keep the code small?

What do you think? Any suggestions?
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

Dirt and Dirt2 in the same cave like seen in Crazy Dream 7 should be possible in the XDC engine.
All it needs is a slight modification to the current graphic file format like this:

Code: Select all

Graphic character set: 

26a0-2700:
Rockford standing still
Bomb status bar sprite

2700-2800: Biter animation

2800-2c00: Text chars

2c00-2c80: Magic Wall animation

2c80-2d00: Biter Switch positions

2d00-2e00: Rockford blinking and stamping animation

2e00-2f00: Bladder animation

2f00-3000: Slime animation

3000-3100:
Slime target
Enemy switch target
Dirt 2
Growing wall switch target
Disolve effect target
Bladder Spender
Bladder target
Clock

3100-3200:
Butterfly target
Magic Wall target
Diamond birth stage 1
Diamond birth stage 2
Diamond birth stage 3
Diamond birth stage 4
Diamond birth stage 5
Titanium Wall and In/Out Box full

3200-3300:
Amoeba target
Voodoo
Boulder
Dirt
Diamond Target
Sokoban Box
Rockford target
Brick Wall

3300-3400:
Space
In/Out Box empty
Firefly target
Explosion stage 1
Explosion stage 2
Explosion stage 3
Disolve and title scroll patterns source
Bomb

3400-3500:
Sweet
Acid
Cross
Diamond release key
Trapped diamond
Chasing Boulder
Biter target
Biter switch target

3500-3600: Rockford left animation

3600-3700: Rockford right animation

3700-3800: Butterfly animation

3800-3900: Amoeba animation

3900-3a00: Firefly animation

3a00-3b00: Diamond animation
 
3b00-3b80:
Enemy switch forward
Enemy switch backwards
Growing wall switch original directions
Growing wall switch alternativ directions
The switch graphics are shifted to the end and only targets are used. Copying the graphics shouldn't to a noticable slowdown, since those switches can be only used once per frame anyways.


Another thing would be some more elements should be possible when reorganized for code optimization. Unlike Crazy Dream 7, this won't require enlarged tables, as it makes clever uses of ranges and certain bit settings.
I though of something like this:

Code: Select all

;can be taken by amoeba $00-$02
;is player = $03-$05
;active player scan = $04-$06
;is slippery = $08-$0a
;can explode = is player || $10-$17
;indestructible = $0c-$0d ($0e by Bomb, depending on setup)
;is active exit = $1a-$1b
;has effect sequence = $40-$7f
;Delayed state = element | $80
;Growingwall direction: h = element & 1, v = element & 2 (vice versa when switched)

.DEFINE SPACE $00
.DEFINE DIRT $01
.DEFINE DIRT2 $02
.DEFINE GUYGLUED $03
.DEFINE GUY $04
.DEFINE GUYBOMB $05
.DEFINE INBOX $06
.DEFINE MAGICWALL $07
.DEFINE WALL $08
.DEFINE BOULDER $09
.DEFINE DIAMOND $0a
.DEFINE STEELWALLDESTRUCTABLE $0b
.DEFINE STEELWALL $0c
.DEFINE TRAPPEDDIAMOND $0d
.DEFINE DUMMY $0e
.DEFINE BLADDERSPENDER $0f
.DEFINE FIREFLYl $10
.DEFINE FIREFLYu $11 
.DEFINE FIREFLYr $12
.DEFINE FIREFLYd $13
.DEFINE BUTTERFLYl $14
.DEFINE BUTTERFLYu $15
.DEFINE BUTTERFLYr $16
.DEFINE BUTTERFLYd $17
.DEFINE OUTBOX $18
.DEFINE OUTBOXopen $19
.DEFINE OUTBOXopenempty $1a
.DEFINE HIDDENOUTBOXopen $1b
.DEFINE EXPANDINGWALLSWITCH $1c
.DEFINE HEXPANDINGWALL $1d
.DEFINE VEXPANDINGWALL $1e
.DEFINE EXPANDINGWALL $1f
.DEFINE BOULDERf $20
.DEFINE DIAMONDf $21
.DEFINE FIREFLYBUTTERFLYSWITCH $22
.DEFINE BITERSWITCH $23
.DEFINE SLIME $24
.DEFINE BOMB $25
.DEFINE SWEET $26
.DEFINE GLUEDDIRT $27
.DEFINE AMOEBA $28
.DEFINE AMOEBA2 $29
.DEFINE ACID $2a
.DEFINE SOKOBANBOX $2b
.DEFINE FALLINGWALL $2c
.DEFINE FALLINGWALLf $2d
.DEFINE HIDDENOUTBOX $2e
.DEFINE GRAVESTONE $2f
.DEFINE BITERl $30
.DEFINE BITERu $31
.DEFINE BITERr $32
.DEFINE BITERd $33
.DEFINE WAITINGBOULDER $34
.DEFINE CHASINGBOULDER $35
.DEFINE GLUEDSTONE $36
.DEFINE GLUEDDIAMOND $37
.DEFINE DIAMONDRELEASEKEY $38
.DEFINE CLOCK $39
.DEFINE WALLEATABLE $3a
.DEFINE STELLWALLEATABLE $3b
;.DEFINE  $3c
.DEFINE HEXPANDINGSTEELWALL $3d
.DEFINE VEXPANDINGSTEELWALL $3e
.DEFINE EXPANDINGSTEELWALL $3f

.DEFINE CLOCKBIRTH1 $40
.DEFINE CLOCKBIRTH2 $41
.DEFINE CLOCKBIRTH3 $42
.DEFINE CLOCKBIRTH4 $43
.DEFINE GUYBIRTH1 $44
.DEFINE GUYBIRTH2 $45
.DEFINE GUYBIRTH3 $46
.DEFINE GUYBIRTH4 $47
.DEFINE IGNITEDBOMB1 $48
.DEFINE IGNITEDBOMB2 $49
.DEFINE IGNITEDBOMB3 $4a
.DEFINE IGNITEDBOMB4 $4b
.DEFINE IGNITEDBOMB5 $4c
.DEFINE IGNITEDBOMB6 $4d
.DEFINE IGNITEDBOMB7 $4e
.DEFINE TIMEPENALTY $4f
.DEFINE BOULDERBIRTH1 $50
.DEFINE BOULDERBIRTH2 $51
.DEFINE BOULDERBIRTH3 $52
.DEFINE BOULDERBIRTH4 $53
.DEFINE BLADDER $54
.DEFINE BLADDERd1 $55
.DEFINE BLADDERd2 $56
.DEFINE BLADDERd3 $57
.DEFINE BLADDERd4 $58
.DEFINE BLADDERd5 $59
.DEFINE BLADDERd6 $5a
.DEFINE BLADDERd7 $5b
.DEFINE BLADDERd8 $5c
.DEFINE BLADDERd9 $5d
.DEFINE DIAMONDBIRTH1 $5e
.DEFINE DIAMONDBIRTH2 $5f
.DEFINE DIAMONDBIRTH3 $60
.DEFINE DIAMONDBIRTH4 $61
.DEFINE DIAMONDBIRTH5 $62
.DEFINE EXPLOSION1 $63
.DEFINE EXPLOSION2 $64
.DEFINE EXPLOSION3 $65
.DEFINE EXPLOSION4 $66
.DEFINE EXPLOSION5 $67
.DEFINE BOMBEXPLOSION1 $68
.DEFINE BOMBEXPLOSION2 $69
.DEFINE BOMBEXPLOSION3 $6a
.DEFINE BOMBEXPLOSION4 $6b
.DEFINE STEELWALLBIRTH1 $6c
.DEFINE STEELWALLBIRTH2 $6d
.DEFINE STEELWALLBIRTH3 $6e
.DEFINE STEELWALLBIRTH4 $6f
.DEFINE INBOXempty $70

.DEFINE ACIDEffect $74
.DEFINE EXPLOSIONEffect $75
.DEFINE DIAMONDBIRTHEffect $76
.DEFINE BOMBEXPLOSIONeffect $77
.DEFINE BOULDERfallingeffect $78
.DEFINE BOULDERbouncingeffect $79
.DEFINE DIAMONDfallingeffect $7a
.DEFINE DIAMONDbouncingeffect $7b
;.DEFINE  $7c
.DEFINE EXPANDINGWALLLOOKSLIKEeffect $7d
.DEFINE DIRTLOOKSLIKEeffect $7e

.DEFINE NONE $ff
.DEFINE EVERYTHING $ff
I don't use enum, so I have full control about their numbers, which is essential for code optimization. What do you think?
Last edited by LogicDeLuxe on Thu Sep 25, 2008 12:23 pm, edited 2 times in total.
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

I thought of not doing XDC as a one filer, but as a loader which loads the engine and passes the names of the cavepack, graphics set, title screen and the highscore file, which are then loaded by the engine itself.

Since I am writing the new engine from scratch, which I do with cc65, doing it as separate files will not only save space on the disk because of there is only one copy of the engine and no multiple sets of the same graphics, it also gives the opportunity to have the engine for other similar systems as the Atari 800, Plus/4 and the C64dtv. The author doesn't even have to worry about, as those systems could be supported automatically, then.

What do you think?
Post Reply