XDC engine development thread (alpha version)

Dustin · Post by **Dustin** » Fri Sep 19, 2008 9:59 pm

I:m sure that this new ck will be great! Finally I can make the whole five- level experience of the RockFort series in a classical VICE look! Can you foresee a rough date when it'll be finished (or at least a beta version of it)?

LogicDeLuxe · Post by **LogicDeLuxe** » Sat Sep 20, 2008 8:02 am

Dustin wrote:I:m sure that this new ck will be great! Finally I can make the whole five- level experience of the RockFort series in a classical VICE look! Can you foresee a rough date when it'll be finished (or at least a beta version of it)?

I'm new to cross development, thus hard to guess. Right now, I'm working on the Title Editor in ca65. The title editor will be the same for both CLCK and XDC.

I think, the Enemydesigner will be next, as there still is no easy way to edit CLCK graphics. That also will be used with both engines. Unlike No One's dirtmod, XDC will generate DIRT2 out of DIRT.

Some translations and bugfixes are also on the todo list of CLCK, and then I will work more on XDC.
I did some initial drafts to see, if the timing would work with a different scroll method, but still not sure. It will probably take slightly more raster time, but at the same time, the physics engine won't have to care anymore about the actual drawing at all, which should result in a more steady speed. Hard to tell for now, though, as there is no physic yet.
One thing, I'm pretty sure though: There will be no more tearing in animations, as animation will be done completely in the vertical border, even on NTSC machines. I'm developing it in the emulator on NTSC since it is the more critical timing with less rasterlines and more frequent IRQ's. Unlike BD1, BD2, PLCK and 1stB, the timers itself will also work correctly in PAL, of course.

The first alpha version will probably have the physic engine with the elements and objects of BD1. Menu, highscore, sound, and more advanced elements, settings and drawing support will follow in a series of beta versions, as work progresses.

LogicDeLuxe · Post by **LogicDeLuxe** » Wed Sep 24, 2008 5:29 pm

Would it be a good idea to support variable amount of levels? Then, the author could create caves with 1, 2, 3, 4, 5, 6 or 7 levels.

GDash currently only supports 5 levels, but even if it stays that way, I could easily build an option to the BDCFF compiler to use less levels. 6 or 7 levels currently would require to write the BDCFF files by hand, though, as there is no editor with that capability right now.

RTADash · Post by **RTADash** » Wed Sep 24, 2008 6:37 pm

LogicDeLuxe wrote:Would it be a good idea to support variable amount of levels? Then, the author could create caves with 1, 2, 3, 4, 5, 6 or 7 levels.

I think having that option would be a good idea. I'm not sure who might use it, but people are bound to take advantage of it if you provide it, so there's nothing to lose.

LogicDeLuxe · Post by **LogicDeLuxe** » Thu Sep 25, 2008 10:43 pm

Should colors and diamond values be adjustable independently for each level? It isn't right now in the current design. Allowing this would increase the cave size by a few bytes, hence I only would do if you really think it's worth it.

RTADash · Post by **RTADash** » Thu Sep 25, 2008 11:42 pm

LogicDeLuxe wrote:Should colors and diamond values be adjustable independently for each level? It isn't right now in the current design. Allowing this would increase the cave size by a few bytes, hence I only would do if you really think it's worth it.

I think having different diamond values would be a good option, especially so you could adjust the bonus diamond points based upon how many are available on a particular level.
Can't think of much use for 5 different color settings though.

LogicDeLuxe · Post by **LogicDeLuxe** » Sat Sep 27, 2008 10:24 am

Another BDCFF update: http://www.gratissaugen.de/erbsen/bdcff.html
I fixed the slime seed default.
New are attributes for CaveScheduling and Amoeba2GrowthProb, Amoeba2Properties, Amoeba2Threshold, Amoeba2Time. Those amoeba2 attributes are just like the regular amoeba, except there is Amoeba2Properties.explode=true|false

Added elements:
AMOEBA2, AMOEBA2d, ACIDEffect, DIRTLOOKSLIKEeffect, EXPANDINGWALLLOOKSLIKEeffect, AMOEBA2bouldereffect, AMOEBA2diamondeffect, AMOEBA2LOOKSLIKEeffect.
I hope, I didn't forget anything this time.

AMOEBA2LOOKSLIKEeffect is mainly intended to switch between amoeba and slime graphics for amoeba2.

LogicDeLuxe · Post by **LogicDeLuxe** » Wed Oct 15, 2008 8:21 pm

For the curious, here is a first demo:
http://www.file-upload.net/download-118 ... 8.prg.html

Done:
- Scrolling. Just move the joystick. Improvement over the original: No sprites used. 11.75 rows of elements visible in contrast to the 11.25 of the original.
- BD1 cave objects. Plus generalized random placement, plus Bresenham lines, ie. from any point to any point in contrast to the limited 8 directions of the original.
- Full element animations. Not all elements are visible in the loaded cave, but their animations are all activated to take raster time anyways.

Diagonal scrolling doesn't work correctly in this version, I know.
For measuring purpose, I used some raster colors:

red = cutting out the visible part of the cave to a 20x13 byte buffer.

blue = translating cutout buffer to 4x4-size-chars. This is split. the first two element rows are done during the vertical blank, and the remaining lines during the visible raster lines ahead.

dark gray= character animations

And now, the physics.

LogicDeLuxe · Post by **LogicDeLuxe** » Thu Oct 16, 2008 11:57 pm

http://www.file-upload.net/download-118 ... 8.prg.html

- Player movements. No snapping support yet.
- Scrolling follows the player with hysteresis.
- Boulders falling, sliding off and can explode player and fireflies. No pushing yet.
- Fireflies movements. Can explode by touching the player.
- Inbox. Hatching is immediately, as no timers are coded yet.

If you die, you can restart the game with SYS4096.

More to come.

LogicDeLuxe · Post by **LogicDeLuxe** » Fri Oct 17, 2008 9:30 pm

How would you like to have the status bar before hatching?

The first line is how BD1/BD2 do it. The 2nd, 3rd, 4th, 5th, and 6th line are possible versions, how I could implement it.

If there are caves with longer names, I will automatically use the standard chars in order to have 40 letters, where 22 of them are for the cave name.

If the game has only one level, the names can have two more letters in the place of the "/1".

So which one do you prefer aesthetically?

RTADash · Post by **RTADash** » Sat Oct 18, 2008 4:21 am

I vote for the first one. (BD1/BD2)

LogicDeLuxe · Post by **LogicDeLuxe** » Sat Oct 18, 2008 9:57 am

RTADash wrote:I vote for the first one. (BD1/BD2)

That one was there for comparison. The 2nd line will look exactly like this, when your cave name is one letter only.
Restricting names to one letter is no option, as the engine shall support far more than 36 (letters + digits) caves together.

What do you think should I do with intermissions? Just display the standard text "B O N U S L I F E"? Or should their names also be displayed during the game?
If not, they will only show up, in the cave selection, given they are selectable.
If yes, should they stand alone, or should there be a similar status line as in regular caves ("player 1, 3 men A/1"), which might prevent the player from realizing that he is actually playing an intermission?

RTADash · Post by **RTADash** » Sat Oct 18, 2008 10:22 am

Maybe the user could choose whether to display a generic text (for all intermissions in a caveset) or specific text (like intermission numbers/names)
Either way, though, I think that the player should always be notified they're playing an intermission from the start (even if it means not using the opening status bar at all) It's not like you need to keep track of your lives during an intermission anyway.

LogicDeLuxe · Post by **LogicDeLuxe** » Sun Oct 19, 2008 12:15 pm

New version: http://www.file-upload.net/download-119 ... 8.prg.html

- Frametime timer is implemented. It is currently hardcoded to 100 ms.
- Hatching delay given in frames.
- Full animated Rockford with walking left, right and blinking, tapping.
- Snapping implemented.
- Working exit. No diamond count yet, thus the outbox opens immediately for testing purpose.
- 4 caves included.

So far, the engine feels a bit faster for PAL, but no significant difference for NTSC. This is due to more raster time as a trade off for simplified physics code.

If you die or can't reach the outbox, press RESTORE to advance to the next cave.

Sendy · Post by **Sendy** » Mon Oct 20, 2008 2:11 pm

Amazing. I'm really looking forwards to seeing where this goes.