Space99 - Development Forum

JamesD · Post by **JamesD** » Sat Dec 09, 2006 2:30 am

Ok, 2nd attempt at this post since the first went to the wrong forum.

You guys are absolutely kicking butt! Nice to see so much progress.
I'm glad I bowed out, I've had zero time and little sleep so I wouldn't have been much help.

Twilighte · Post by **Twilighte** » Sat Dec 09, 2006 2:39 am

Hi James, i hope you have recovered well from the Medical emergency.
Thanks for your kind words. We have certainly made alot of headway, thanks to your help and Chemas considerable talents.

Chema, will we be adding load routines for each Mission(level) now we have disc capability?
I think Dbug is now right that Tape is perhaps beyond the scope of this project and Disc is the way to go.

BTW, just finished another batch of inventory items, and working on isometric items too

JamesD · Post by **JamesD** » Sat Dec 09, 2006 6:15 am

Hi James, i hope you have recovered well from the Medical emergency.
Thanks for your kind words. We have certainly made alot of headway, thanks to your help and Chemas considerable talents.

Actually I'm fine, my mom had a stroke and I'm just helping the family deal while she's in rehab. She'll be home after the start of the year btw.

Not sure what I did to help buy you're welcome I guess. LOL

Twilighte · Post by **Twilighte** » Sat Dec 09, 2006 8:59 pm

Chema, i've done all the isometric and inventory items for the plot previously sent. Both match. The only item in both sets that has no link in the game now is the spanner.

http://www.defence-force.org/ftp/forum/ ... /items.rar

And the screenshot

Each item should be self explanatory, however from left to right...
Commlink,Battery,Notepad(and component list),inductor,chip,Resistor,Plant Juice,Spanner(?),Medkit,Key,Compound,Fuse and Relay.

Please tell me how you would like the colourful inventory items sent?
I can send as a HIRES image or sequential, whatever you want.

I need you feedback regarding the plot before i can proceed and link the plot to the Map and therefore make changes.

Post by **Dbug** » Sun Dec 10, 2006 12:24 am

Twilighte wrote:And the screenshot.

You are mad

Seriously, your mastering of the video inversion still amaze me

These objects kicks asses, and are the kind of thing that show how sometimes the Oric graphic system can badly outperform the Spectrum

Twilighte · Post by **Twilighte** » Sun Dec 10, 2006 12:49 am

Thankyou Dbug, Especially from you that is the best compliment.

I'm just so honoured to be asked to do the graphics for this fantastic Oric game, if we ever finish it, i think it will be the ultimate game. (pun possibly intended hehe)

Chema · Post by **Chema** » Mon Dec 11, 2006 11:27 am

Thanks for everybody's support! I had some days of holidays, so that is why I did not post anything new

Your items are incredible, John. I can't wait to add them to the demo. I would need, if possible however, the linear version and, even better, the raw data in a file to add, something like:

Code: Select all

commlink 
.byt xx, xx, xx, ..
.byt xx, xx, xx, ..

commlink_mask
.byt xx, xx, xx, ..
.byt xx, xx, xx, ..

and, for the inventory (color items)

Code: Select all

commlink_inv
.byt xx, xx, xx, ..
.byt xx, xx, xx, ..

If all the inventory items had the same size (3bytes x whatever) it would be perfect, as all the code that is currently working for displaying the inventory would still do.

I normally use pictconv to generate data, but it does not work with color pictures (at least I think so, when it is just a direct translation) I know it might not be hard to do this from the data, but it would help me a lot to have them already in sources.

On isometric items, I did not give them a closer look, but they look fantastic. Only thing is that we could benefit from using shapes that could be given the same mask. That is impossible for the commlink, but in the demo the medkit and the book both have the same mask (they are just blocks). Also this helps a lot within the game, as they all have the same logical 3D size (5x5x4) and collisions are more... accurate.

On another things that have been pointed out, I need to modify the room editor to include the two color possibility and convert the map file. Indeed scanlines will only be used when necessary.

Even with the disc possibility, I would not think on loading levels from disk for now, even if it would not be a problem (I can load map data in crunches directly and everything would work regarded that the room to load is there and contains all the data). As you pointed out, it would probably mean we would make the game bigger and bigger and never be released. Anyway, we allways have that possibility.

In addition, what I think would be perfectly possible is saving games. My oppinion on this is "keep it simple". We can use a given sector on disk to save/load all the necessary data (I think 256bytes is enough). You would only have ONE savepoint that will be overwritten each time

and load/save would only be accessible from information posts

.

Ok, as we can use more sectors easily we might be convinced to have more saving slots, but time will tell...

I have been working on the program in my free time, and I made some more progress... however nothing really visible as to post an update. Anyway sufficient as to start making suggestions on the plot and how to implement some things

Twilighte · Post by **Twilighte** » Mon Dec 11, 2006 12:59 pm

Your items are incredible, John.

John?
Jonathan or Twilighte is fine, but please not John.

I can't wait to add them to the demo. I would need, if possible however, the linear version and, even better, the raw data in a file to add, something like:

Not a problem, i'll do this as soon as i get back.
Can you give me a memory map of what we have so far? I am a little concerned with the size of all this extra stuff.

If all the inventory items had the same size (3bytes x whatever) it would be perfect, as all the code that is currently working for displaying the inventory would still do.

They are so not a problem

I normally use pictconv to generate data, but it does not work with color pictures (at least I think so, when it is just a direct translation) I know it might not be hard to do this from the data, but it would help me a lot to have them already in sources.

I also use pictconv or pchires. Pictconv can translate Colour graphics like this, but i will always redo the images on Euphoric using HIDE, so it will be easy enough to place in the format you request.

On isometric items, I did not give them a closer look, but they look fantastic. Only thing is that we could benefit from using shapes that could be given the same mask.

All isometric items conform to the format you mentioned, all being 3xSomething. The mask may be a problem but i'll see what i can do.

Even with the disc possibility, I would not think on loading levels from disk for now

Shame, but only had this in mind because of my concerns over the issue above.
I am also thinking we may need to scrap the 'Confrontation' in the plot if memory does not accomodate it.

This is part reason for making Robot one frame.

I think 256bytes is enough

Yep, fine.

...start making suggestions on the plot ...

Yes, i need to have some feedback before progressing with map changes. At work currently so no access to email incase you've sent me feedback already?

[/quote]

Post by **Dbug** » Mon Dec 11, 2006 2:20 pm

Chema wrote:I normally use pictconv to generate data, but it does not work with color pictures (at least I think so, when it is just a direct translation) I know it might not be hard to do this from the data, but it would help me a lot to have them already in sources.

If the items are stored verticaly, PictConv can normal convert them without any problem.

It seems that items are conceived to be displayed assuming that PAPER is black, and that there is a 6 pixels separation allowing for a INK attribute change. Assuming that the items themself are 12 pixels wide, all you need is to store them verticaly in a 18xNnnn picture, and normaly PictConv will convert all that without any problem in source code format.

It if does not work, then there is a bug, and I shall fix it

Chema · Post by **Chema** » Tue Dec 12, 2006 11:17 am

Twilighte wrote:
Your items are incredible, John.
John?
Jonathan or Twilighte is fine, but please not John.

Oops sorry for the confusion

, Twilighte

Not a problem, i'll do this as soon as i get back.
Can you give me a memory map of what we have so far? I am a little concerned with the size of all this extra stuff.

Sure. Yesterday I added a first test for the robot problem and it was much easier than I expected... I added a function for repairing it:

Code: Select all

repair
.(
    asl
    asl
    tax
    lda _moving_chars+3,x
    ora #%10000000 ; Set automovement flag ON
    sta _moving_chars+3,x
    rts
.)

and added a new case on the action table. For this test, I used the commlink object (Helena's in this case), but can be changed easily:

Code: Select all

actions_char
    ...
     .byt ZX81_R
     .byt HCOMMLINK
     .word repair

and it worked! I want to add a way of stopping it again and some extra code to be able to remove/add items from a character's inventory at any point (not only with user interaction), so we can change one for another, use an item for something (and it dissapears from the inventory), give things to characters...

In addition I partially solved the lift management. Now it prints a message "Select level: " along with a level number (this can change) and the user can change it with 'M' and 'B' keys (up/down). CTRL selcts the level and operates the lift. Again it is possible to move between levels

I also had to add some code for handling timers (related to alpha power and life support systems, as well as character lifepoints) and solving some bugs, and it is as follows:

Code: Select all

Zero-page variables:
$00-$01 (TimerCounter and KeyCode)
$50-$8b (rest)

Program start $500
NOISE: 6450 bytes
WHITE: 2727 bytes
MAPLOAD: 588 bytes (loading room from map)
SPRITE GFX: 3732 + 48 bytes
INVENTORY ITEMS: 90 bytes of extra data, not pictures yet, but some extra stuff for test that can be removed.
TILE GFX: 9770 bytes
DISC routines: 347 bytes (this will probably change, as some tweaking can be done)
C code: over 500 bytes+256 bytes of stack (osdk_stack) (basically load world data in overlay ram)
Current game code: over 4K (including all your routines and charset and needs tweaking, and texts which are over 300 bytes)

End of code $751f (a total of 28703 bytes)

Overlay ram: start at $c000 and uses over 9.7 K for world data (in fact 38 sectors of 256 bytes are loaded) up to $e600.

Even with the disc possibility, I would not think on loading levels from disk for now
Shame, but only had this in mind because of my concerns over the issue above.
I am also thinking we may need to scrap the 'Confrontation' in the plot if memory does not accomodate it.

As you wish. It is not difficult to add, I suppose. Mostly world room data, but, as you stated, we will be adding features continuously and never finish anything... Anyway, if needed, world can be splitted in parts and those loaded whenever needed.

Do you think we are facing memory problems? I know sounds will take a lot of space, as well as texts (if we put too many, even if we can compress them), but we still have over 10K (up to $9fff) and some space in the overlay area.

BTW I tried your screen layout (cloading before the game

) and I wondered if it could be possible to swap the character images, so Koenig is on the left side. It is not a problem, really (can change the code to reflect current layout easily) but I feel more confortable with the "main" character on the left. Oppinions?

Also the lifepoints meter... can you provide a routine that updates the meter with a given value? We can have 4-5 bits for this, so 16 or 32 lifepoints in total (I'd say 16, but it is up to you), so I can call that routine with the current level in A and, say, reg X=0 for Koenig and 1 for Helena so it updates.

If it is quick I can even call it in every game loop!, else only whenever these values change.

If the items are stored verticaly, PictConv can normal convert them without any problem.

Will try as soon as I have time.

Cheers.

Twilighte · Post by **Twilighte** » Wed Dec 13, 2006 2:06 am

I wrote

Not a problem, i'll do this as soon as i get back.

Ooops, not managed to do anything tonight, apologies. Will try to get it done before the end of this week. Work has been a real stress headache today.

Program start $500

Can we not start at $400 now?

Do you think we are facing memory problems? I know sounds will take a lot of space, as well as texts (if we put too many, even if we can compress them), but we still have over 10K (up to $9fff) and some space in the overlay area.

Well, i reckon Music and SFX will take about 5K. I have alot of ideas for sound effects and will at some point list the Sound Effects we require in the Space99 Music forum.
I also think we should concentrate on Text memory and content now. At least get the big areas out the way.

BTW I tried your screen layout (cloading before the game ) and I wondered if it could be possible to swap the character images, so Koenig is on the left side. It is not a problem, really (can change the code to reflect current layout easily) but I feel more confortable with the "main" character on the left. Oppinions?

Hmm, what about this?

Ok, i'll also convert to hires and send you updated HIRES file.
Also will include updated item format in text file and life points update routine. All stuff for tomorrow since a bit late now.
I would recommend you only call life update routine when life changes. Speed over jsr duplication

Chema · Post by **Chema** » Wed Dec 13, 2006 11:51 am

Greetings... more things.

Twilighte wrote:Can we not start at $400 now?

Unfortunately not yet. The disk routines I am using are supported by data and routines in page 4 (from the DOS, I think). Switching overlay ram on ad off is, for instance, jsr $04f2, but also there is other code that is more difficult to "patch":

Code: Select all

lda $04fb   ; current drive/side selection

I have a newer set of routines with seem to avoid using page 4, but I was not able to make them work yet... I will contact Fabrice and ask for his help. If this is possible (which should be) we gain another 256K and also probably the whole page 2, if we are not to use any ROM routines.

Do you think we are facing memory problems? I know sounds will take a lot of space, as well as texts (if we put too many, even if we can compress them), but we still have over 10K (up to $9fff) and some space in the overlay area.
Well, i reckon Music and SFX will take about 5K. I have alot of ideas for sound effects and will at some point list the Sound Effects we require in the Space99 Music forum.
I also think we should concentrate on Text memory and content now. At least get the big areas out the way.

Well that is quite a big amount of sound and SFX

Great ! We can also put them in overlay ram (we have over 6 K free there). For now I only switch to overlay ram for loading room data, and then get back to rom just to use kbdclick routines

. Soon we will be able to have overlay ram active all the time (unless we need rom access at any point).

Hmm, what about this?
pic removed

Great for me. Thanks.

On another matters, I was able to convert your colored pictures (pictconv says they need to be 240 pixels wide!), even if they needed some tweaking to put back black paper in some cases or to set white ink in others (like the notebook). As I did that by hand I might have some errors, so I will compare them with the sources you'll send me.

So now inventory is full of color

. I have added the battery and all the logic around the cleaning robot, including the fact that its description states also if it is unpowered or working. Also added code to support a first message on the information posts: Current status of power and life support systems. I realized we lack a percent sign in the character set (as well as a dash '-', but this is less important). Text size is 418 bytes and inventory items take just 210.

All in all we have crossed the 29000 bytes barrier and are currently in 29285.

Twilighte · Post by **Twilighte** » Wed Dec 13, 2006 9:18 pm

Ok, below is item file as 3 value delimited .byt thing.

http://www.defence-force.org/ftp/forum/ ... emdump.rar

You mentioned you wanted some different items, but i think we should settle the plot then we'll know exactly what replacements need doing.
I'll work on it as much as i can, but it is a time consuming process

Post by **Dbug** » Wed Dec 13, 2006 9:48 pm

Chema wrote:On another matters, I was able to convert your colored pictures (pictconv says they need to be 240 pixels wide!), even if they needed some

Yep, I checked the code and it was indeed wrong.
May you check this page and see if the new pictconv solve the problem ?
http://forum.defence-force.org/viewtopi ... =1045#1045

Please, keep your existing version of the OSDK on the side, do not overwrite it, I can't guarantee that this version is bug free because I rewrote a lot of things internaly to ease the maintenance

Twilighte · Post by **Twilighte** » Wed Dec 13, 2006 10:22 pm

Also, i notice that you do not use the Selector cursor for items that i used in the original image. The cursor is duplicated above aswell as below the selected item.
The reason is possibly because if it highlights the right item for Koenig on the left, it will corrupt the border (Because it needs an attribute to switch back the colour to white(the row colour being Yellow))of the Room name box. Easy answer is to delete the pixel on both sides but it won't need the attribute to switch back because this row is not used for the Characters in the box.

I also took the liberty of raising the extreme left and right graphics to allow an attribute to switch to Yellow.
The new attributes are shown in Magenta. The space for the items in Cyan.
Below is the updated hires image on the dev disk
http://www.defence-force.org/ftp/forum/ ... pace99.rar

Please note, when i update the items, you can generate the text dump of 3 bytes delimited items using the Dumpicons program on the disk. It will dump to Printer.txt so make sure it is switched on in euphoric.

Finally, the item cursor graphic is a row of 3 bytes. $ED,$D2,$ED