Space99 - Development Forum

Want to talks about games you like, would like to see developed on the Oric, it's here.
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Twilighte wrote: Well i can do this, it is not a problem. But i had though it would be rather cool if the items in the inventory area where in colour, then when placed on the game area, they would be the same graphic but without colours. However i can see the problem!, because your routine for plotting cannot be expected to filter out colours.
Ok, i shall change it. However i'd still like to keep the idea of white selected item, blue non-selected item.
Do as you wish... It was just because of the memory constraints, nothing more. If we are to go for using overlay ram I don't see the problem and it would be really nice!

ok, its Helena 'hair do' that the problem lies with. It would have been fine if we'd chosen Sandra Bain instead, but she's just not important enough?
:)
Well they do and they don't. Some frames are 32, some are 36. The thing is the natural way of walking means that when a persons legs are together, they will be taller than when they are apart. You can see this in most sprites.
But if you need to edit them to get them to work under doors, then thats ok with me.
I will try to make them all fit in the correct size, even if inside the picture, some will be just 32 pixels heigth and others 34 (not 36). Also I might re-organize the animation, so the one with the legs together is the first frame. This is just because I have a WHITE function (white_standstill) that puts the char back onto the first frame. I planned to use it for later animation where the char extended his arm, but might be used for when you stop moving for some time.
Can you read back a couple of messages Chema, i sent a message on Mon Nov 20, 2006 1:06 pm regards a better system. Please give me feedback, if it is of any value, then this would ease on memory issues.
I am not sure if you mean the one about the passcode system. I like it and it would be perfect for disk version. Anyway after having the possiblity of disk access many new things can be done. BTW, I am sure I have Fabrice's code for sector_read and sector_write we used in Pinforic... I won't understand them at all, but might be useful.
Yuck!, ooer, i think we should consider other avenues before cutting graphics down. See previous suggestion.
The thing is, Dbug contacted me regarding this recently and made be realise that the majority of people who will play this game will never use cassette but either disk on real Oric or Euphoric. Therefore i think regardless whether we opt for disc saving, we should use the top 16K.

I don't think 6.5K will be enough for game logic, item gfx, text and music.
Also, i wrote a 1K game, not 4K. That's Dbug, and Dbug only had a 4K tape image, the generated memory use was far larger!
:( Well I don't have a real Oric with disk. Anyway I think we should use the top 16K too. That should open a whole new world of possibilities... more characters, more text, more rooms and graphics, more puzzles :)

To me it is way more simple to have a single action key and select items. The objects you interact with should be logical enough to assume you do not wish to use the commlink to kill the alien, or the gun to open the door with.
Also if you look at modern games, they have evolved to use a similar scheme. In Half-life you have two keys for selecting weapons (admittedly you can also select weapons with 0-9 but i never use that) and one action key.
Agreed then. I don't mind, really. We can use two keys for iterating through the inventory. The problem here is that I was thinking of using an event of interaction with no item (by hand, like take something). Maybe the good idea is to remove such a thing or think of something else (like what you stated).
That sounds fine.
Unless we also add some kind of lifepoints and, whenever a character is low, it could move slower or need help. Helena could be the only one able to refill that :) We can think about that later anyway, I suppose.

About colors... we can add different inks depending on the room (better the type of room). For example red for power stations or computer rooms, cyan for quarters, white for passageways and Main Mission, yellow or green for rest areas... I am too bad at colors, but we can came up with a consistent scheme that could add some 'color' to the world. What do you think?
Ok, no problem, i can write that before next week.
LOL, then I *have* to hurry up with other matters...
This would ease using my decompression routine a lot. And if we don't rely in BASIC the dictionary (256) bytes could go in page 4, if I am not wrong.
Page 4 is used for Disc routines (if we opt to use it). Under tape only, page 4 is free. But i would recommend if we decide to use page 4 we might aswell expand the memory to run from page 4 to 9FFF :)
We also have page zero and 2.
It all depends on what we are going to do regards tape or Disc or that idea previously posted.
I edited the post just after you answered, I think... I meant page 2. Page 0 is used by (software) registers and temporal variables. I use it A LOT and also I use the OSDK C parameter passing convention (using sp) in functions, so I guess page 0 is no more free :(

I think we could use memory as you state, but if we are to use the disk access, then go from 500 (or maybe even less to 9FFF ! That is quite a lot.
The problem with the Oric, in comparison to the C64 or ZXSpectrum, is that graphics will always use 25% more memory than on other machines.
And this isometric game is very big on graphics :?

It is indeed
Unless i radically reduce graphics (Which i am very much against), or a complete rethink of game code(yuck!), or no sound with tape version (UGG!!) i think we should use overlay 16K ram and make disc only.
Agreed. The only option left was reduce the number of rooms in 10-20, which could give us up to 1.6K more, but I like having such a HUGE map indeed.
tbh Chema, i don't know. We'll have to try it before i can say. :?

I've also just redone the same game screen using 5 high characters, which would be faster and more memory efficient than 7 high.
A couple of other changes too. Let me know if this is ok?

btw, i can convert this image to hires, and give you tap?
I like it. It is a little less readable, but enough for me. Would like to hear more oppinions. A tap would be nice, so I can load on Euphoric, but it is not really necessary.
JamesD wrote: Sorry guys... a major family medical crisis. Until further notice I don't have time. Sorry. If that changes I'll let you know asap.
Sorry to hear that. Hope everything evolves positively.
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte »

Hi Chema, i will try to keep this verbose... ;P
If we are to go for using overlay ram I don't see the problem and it would be really nice!
Ok, i would like to suggest the following...
For the first game, we use the password system, make disc only but do not have disc routines.
This in some ways seems silly but what i am trying to achieve here, is a way to avoid you thinking "hey, we have loads more virtual memory!, so lets use it... and 10 years later the game is released...". I've seen this happen too often in the past with my own and other peoples projects!
The first game is always the tester of our metal. ;)
This also avoids any glitchy load/save routines and gives us the whole 65536 bytes to play with (Well almost).

We then use Dbugs crunch routines which take a 64K image and crunch it into 40K (Which shouldn't be a problem). :P
The Oric Disc boot sequence then follows for the game...
Load any nice intro and exec
Switch to HIRES (ROM Call is fine) if not their already.
Load loading screen
Load crunched game and exec. (Which will take out ROM)
Game starts
HIRES now displays title, with password option and controller options.

The passcode will be 8 character. Each character can be A-Z,a-z,0-9, * and & giving us 6 bits per character. This would then be split as follows...
7 Bits Room Number
8 Bits Level (relating to items posessed and alpha status)
4 Bits Currently Selected inventory * 2
4 bits lives * 2
+ 25 bits for anything else. :)

With JamesD unavailable now (I Hope everything turns out for the best James?) i will have to think about the tunes in Sonix instead soon :?
'color' to the world. What do you think?
Great idea.
It may also be possible to alternate similar colours like Magenta and Red, Cyan and Green, Yellow and White to produce some more interesting screen colours (alternate down the screen).
I use it A LOT and also I use the OSDK C parameter passing convention (using sp) in functions, so I guess page 0 is no more free
Ok, this might be an issue Chema, i will need at most 16 zero page variables for the irq routine (Music, key reading, timer).
I don't mind where they will be in page zero, but expect them not to be fragmented (ie. $10 to $1F is fine but $10 to $17 then F3 to $FA would not be good).
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

About the colors, Twilighte is right when he says that we can use alternated scanlines. We are not obliged to use pure colors, alternative two colors on odd/even lines works very well.

Also consider having a blinking routine that change between two complete sets of colors at a specific interval, for some of the room for example if an alert is enabled. Like switching between RED and GREEN ink.

It's kind of violent, but can give a feeling of emergency, and really indicates that something is wrong.

About the zero page usage, if Twilighte stops thinking in hexadecimal, and everybody agree on using automatic allocation in zero page, it should be easy for everybody to get zero page usage easy to deal with:

Code: Select all

  .zero

twilighte_variable_1  .dsb 1
twilighte_variable_2  .dsb 2

  .text

_TwilighteRoutine
  .(
  rts
  .)
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte »

About the zero page usage, if Twilighte stops thinking in hexadecimal
ewwww, i can't... i can't live without my blessed Hexadecimal! :)

Ok, it is important that i point out that we mustn't push out the boundaries too far. We may have scraped another 16K but this will easily be eaten up by the other stuff.
We have the Space:1999 logo (title) to fit into memory, like this...

Image

We also have the music and sfx which will take at least 6K.
Then we have game code, Title code and other stuff. It is best at this stage that if you agree to do this passcode thing Chema? that we get all the minimum parts together into a version of the finished game, then if we find spare memory, we can fill it.
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Ok... trying then to keep this verbose ;)...

I have made a few minor changes to the world map, mainly removing unused tiles from the tileset and adding the SPECIAL code bit for every door and info post. The result is here:

http://www.defence-force.org/ftp/forum/ ... -chema.zip

Be careful to save your data first, and check for any inconsistencies. I also added a new version of the editor that handles the SPECIAL flag correctly (the old one didn't). One thing you could do is removing any unused rooms (some seem to be there just for testing purposes) and check connections between them.

I also took the liberty of creating two aditional rooms (195,196). This are not intended to end up in the final game, but to serve as an idea about the look of Main Mission (remember we talked about it?). It is an schematic of how I humbly think it should look, more or less... However, feel free to let your imagination flow and discard this completely :)

I used VDUs to simulate the windows, and reduced the used rooms to just two, so maybe minor adjustments should be made. I left a south door in the room with the windows in the south wall, even if it should not be there really (that wall is full of computer panels. I placed two doors to the west in that room, at each side of the big screen, as it was in the series, even if those two doors should lead to the same room (a doorway in the series, if this serves...).

I also think we would need a Computer room... I am sure I saw pictures of it. It is lighted in red and full of... well computer panels. It is the heart of Alpha's computer system.

May I come up with a couple of suggestions? They are just that, so discard at your will.

About tiles: I find it strange how monitors look when they are turned with respect to the person who should use them. I know this is because we removed one tile with the back of the monitor, but still...

On the other hand there are several tiles that I think we could change/remove:
-The gunrack (Space 1999 guns are not like that btw), which could be substituted by a STORE CUPBOARD or SHELF. I don't think we would use guns in this game (I would have to program projectiles :) ), but in that case, we can put the gun object (pickup) on the shelf.
-The INSET_BOTTOM, which is a kind of wall I can't identify... and is sparsely used (I think).
- The RADSUIT-LOCKER, which is an incredible graphic, so I would leave it there even if it is just to contemplate it, but in case of need we can change it for the FILLING_CABINET.

We can use spare tiles for picups or for open drawers or cupboards, or animations, so the more we have the better. However we are not in need now, so it is your decision. I could convert all the pickups in characters (that obviously don't move), so we save tilecodes.

About zero page... well I used first all the tmpX, opX and so from the C compiler and then grab a few more for the drawing routines. If I recall correctly I used up to $8A, but I think if I use further, the generated C code complained (maybe corrupt the C stack? DBug can clarify this indeed).

I suppose that saving regs is out of scope, as it would be me disabling interrupts in the critical routines (which means ALL the drawing part). I am a bit lost here...

I completely agree with not pushing the boundaries too far. In fact the step towards changing the code to use the overlay ram looks quite difficult to me for testing things, as the only time I did so, we loaded data from disk into overlay ram and used it, so it was quite easy. Maybe we are approaching the time where I should release the sources and concentrate on the engine and routines here and there, while you give shape to the game ?

Colors... maybe something can be done. I reserved some bits for ink color, but others which were reserved for room size could be used to get the final combination... I have to think about that indeed! The blikning DBug suggested is something I also had in mind.

About the passcode... I feel it is a better idea each time you come up with a new suggestion. If we keep the possibility of getting a passcode to certain moments and certain positions (say the InfoPost, so we are sure there are no open doors or moving characters around to keep track of), then it is quite valid. I think we won't have somthing as lives, but we could have a level of health for both Koenig and Helena. Anyway this can be delayed to later stages. Ah.. and I posted the disk sector access routine Fabrice developed to use in Pinforic (6502 programming forum). We also could use it even if it is only to save/load the game.

Anything else I forgot? Ah yes, I included the possibility of moving backwards :) and made some initial skeletons for other functions in asm, so I think I will progress faster on that areas now.

I want to test the bubble idea, but that will require some more time...

Regards,
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte »

ok, got a bit carried away with the graphics. I will get your routines done soon, but for eye candy (From Euphoric)...

Image

I have changed the bottom text borders to allow colours to be set up prior to displaying text.
I have also removed the lives and placed a single bar to indicate life (0-20 currently).

And you can now get the tap here..

http://www.defence-force.org/ftp/forum/ ... pace99.tap
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

That screen looks amazing. I would love to read through all of this but I haven't slept in 40+hrs and have an early road trip tomorrow.
The progress looks really good and that's about as professional looking as I could expect a game to be.
I won't be able to read the form for a while but I made some comments in the Space99 Music and sound effect forum.
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Twilighte wrote:ok, got a bit carried away with the graphics. I will get your routines done soon, but for eye candy (From Euphoric)...
Very nice indeed Twilighte!

I will also add something. As promised I made a small test for bubbles with the already used double buffer area:

Image

Advantages:
- Functions for clearing, drawing, restoring background etc are already implemented. In fact it's just a matter of writing characters in the buffer and call one function. Also it is very easy to position over a character (one function call and some adjust of a rectangle parameters).
- Changing its size is just a matter of stating a new heigth or width. Beware, though, the image shows the maximum size.

Disadvantages:
- Small area. What you see in the capture is the biggest size. And no, I cannot extend it so it has more characters per line and less lines.

The biggest issue is that the off-screen buffer is intended to be drawn from bottom to top, so the "dump" area is allways set on the low-left corner of a rectangle. This means that, for getting smaller bubbles, we have to either calculate the size (in lines) previously, or draw from the end of the string backwards, which could be unconfortable.

Of course we can write new functions to dump/restore the screen so we can change how the buffer behaves, but with this approach I only wrote two simple functions: the main one, where the rectangle for a given character is calculated (one function call plus some adjustments to place it avobe the char and prevent it for going offscreen) and manages the bubble (see below), and another for printing a string char by char until it hits a 0.

The main routine, basically performs:

Code: Select all

    ; Clear the buffer
    jsr _clear_buff
    ; Draw the text
    jsr print_bubble
    ; Put the bubble onscreen
    jsr _paint_buff
    ; Get user key
    jsr _getchar
    ; Clear the buffer again
    jsr _clear_buff
    ; Draw background contents
    jsr _draw_room
    ; Restore background
    jsr _paint_buff
Of course all details are left, like a small lines at one corner with a triangle to point to the character who is speaking, but this should show if it is the correct approach or not.

I would not matter about the size much, because I think we should keep bubbles for small texts and put longer messages on the message area. Else the player could feel annoyed. Oppinions?

EDIT: And, for the audience, this is an Euphoric screenshot with the current version plus Twilighte screen design (loaded it before the program, so I had the honor of being the first one to move around Alpha with the beta version of the screen layout :) )

Image

EDIT2: BTW I have tested another couple of things. I have updated the white_showroom function, so it now gets two colors as parameters and uses them for getting alternate scanlines with each ink color, as suggested.

I have also done a proof of concept for objects that could be pushed. It works fine, but I have trouble when they are put "inside" doors, as either I let the door close and it "traps" the object or I don't and problems might appear in some circumstances (when the character exits the room through a wall with no door). It is a source of problems, but at least, it works OK. I think it's not to be added for this game, unless in a very specific (and controlled) situation.
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte »

Hi Chema, that isometric view looks slightly shifted to the right (perhaps by one byte. Can this be corrected or is it as a result of my graphics?

Also, i started to write the put_char but stumbled on something. Do you want a common cursor and have commands like...

relocate_cursor
put_char

Basically this put_char tracking the cursor position :)
Or just send put_char x in x register, y in y register and character in a?

Also, my screen calc routine for x/y relied upon ylocl/h which is a very fast method of locating the screen loc from simple byte alligned X and Y coordinates.
ylocl/h basically holds all HIRES screen locations down the leftmost column of the screen (Therefore 196 bytes each) so we index this with Y and then adds X.
Do you have equivalent table/s?

I will also provide put_colour_normal and put_colour_combo to place colours on the screen for text colour.

I have an idea (Though a little drunk currently). If you concentrate on using the lower memory ($500-9FFF) and let me know if you need to relocate any temporary buffers or text blocks to top 16K if you run out of memory, then i will write the irq routine, music player+data, keyboard routines, put_char routines and title code in the top 16K.
I will then publish these here.
I can test my stuff separately here. I will also place the title graphic in top 16K.
Then we may get Dbugs help to crunch these to 40K, generate the file and upload with link here and then either(or both of us) can test the code . A bit like me writing the rom and you writing the ram :P
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Twilighte wrote:Hi Chema, that isometric view looks slightly shifted to the right (perhaps by one byte. Can this be corrected or is it as a result of my graphics?
Neither. It is a result of the room graphic. Some rooms, like this one, have a wall setup which make them look like shifted. Mainly those with no walls in a given direction, as they extend into that direction. Little can be done, but once you start moving around you get used to see these changes, depending on room shape. "Normal" square rooms are perfectly centered.
Also, i started to write the put_char but stumbled on something. Do you want a common cursor and have commands like...

relocate_cursor
put_char

Basically this put_char tracking the cursor position :)
Or just send put_char x in x register, y in y register and character in a?
Um... oh... I am not sure. What do you recommend? Remember my lack of experience in programming games. I'd say I would like to have separate routines to print texts on the main area, room label and bubbles and just concentrate on calling a put_char or print like routines.

I suppose we would dump texts on the main window and let them scroll, passing something like character 10 or 13 to cause a carriage return. For room labels, it would be easier just to decompress the label on a given memory area and call a routine that prints it. For bubbles, something like what is working now could suffice, where I call a print string or putchar routines. Maybe in this last case, if the text is bigger than what could be shown on the bubble it can show "..." and put the rest once the user pressed a key. We can stop everything else in the meantime.

If we are to use these bubbles, I can provide the code, even if it is now ugly and unoptimized.
Also, my screen calc routine for x/y relied upon ylocl/h which is a very fast method of locating the screen loc from simple byte alligned X and Y coordinates.
ylocl/h basically holds all HIRES screen locations down the leftmost column of the screen (Therefore 196 bytes each) so we index this with Y and then adds X.
Do you have equivalent table/s?
Do you mean a kind of pixel_address routine? Sure.

I have an asm version which takes (x,y) pixel position and returns the address of the scan and a byte with all zeros but the bit corresponding to the pixel inside the scan. All params and results use zero-page variables, but I also have a C-wrapper that follows the C-calling convention (using sp and x and a registers). In fact this function works in double-buffer mode, where it uses the off-screen buffer, and in normal mode, where it uses the Hires screen. It uses a 200-byte table for getting the address. Another table of 240 bytes is for performing the division and modulo 6.

It might not be as fast and I am not sure even if it is what you need or not. I wonder, however, if you need to put text ANYWHERE in the screen or just keep to text areas, which might simplify things a lot (shorter tables, for instance).
I will also provide put_colour_normal and put_colour_combo to place colours on the screen for text colour.
Fine :)
I have an idea (Though a little drunk currently). If you concentrate on using the lower memory ($500-9FFF) and let me know if you need to relocate any temporary buffers or text blocks to top 16K if you run out of memory, then i will write the irq routine, music player+data, keyboard routines, put_char routines and title code in the top 16K.
I will then publish these here.
I can test my stuff separately here. I will also place the title graphic in top 16K.
Then we may get Dbugs help to crunch these to 40K, generate the file and upload with link here and then either(or both of us) can test the code . A bit like me writing the rom and you writing the ram :P
I like the overall idea. I am not sure how all the process for crunching and decrunching is done for testing (I understand the idea, but don't know how it would affect the compile/run/test loop I currently do with a couple of keystrokes).

I can also upload the current source code and explain the general layout. You would only need to touch a couple of files to be able to include your routines. If we need space for testing, it could be as easy as using only part of the world data or gfx. If we coordinate just a bit, we can work over the same project easily. Let me know what you prefer.

BTW Twilighte, have you checked the map I uploaded and commented about a couple of posts back? And did you read my answer about the zero-page usage? I fear DBug can clarify how the C Compiler uses this area and see if, once we get rid of C or keep it to a minimum, we could find space for that area you need.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Chema wrote:I like the overall idea. I am not sure how all the process for crunching and decrunching is done for testing (I understand the idea, but don't know how it would affect the compile/run/test loop I currently do with a couple of keystrokes).
Well, I sure hate wasting my time with complicated stuff, so I generally make sure that generating a packed version of something does not cost me much time than doing a non packed version :)
ie: I can try to get that in my next OSDK version, as a generation option to generate a compressed executable using FilePack (Then the file would contains a self-unpacking routine).
Chema wrote:And did you read my answer about the zero-page usage? I fear DBug can clarify how the C Compiler uses this area and see if, once we get rid of C or keep it to a minimum, we could find space for that area you need.
The C compiler does not use anything out of the OSDK zero page variables declared in header.h
By default this area starts in $50, but we can sure have it somewhere else if necessary.
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Dbug wrote:ie: I can try to get that in my next OSDK version, as a generation option to generate a compressed executable using FilePack (Then the file would contains a self-unpacking routine).

The C compiler does not use anything out of the OSDK zero page variables declared in header.h
By default this area starts in $50, but we can sure have it somewhere else if necessary.
It would be a nice idea, Dbug, even if I am not able to see if it would do for our case...

I have been thinking that it would be nice to move room data (9.5K) or gfx (10K) to overlay, instead of your routines, Twilighte. In that way we can extend the world if needed with more rooms or add more characters or graphics easily. Also the compressed text or sound data can be put there if necessary.

That way we have all the code in normal memory and it would be easy to handle/change as we will have the sources at hand.

I am not sure how this could be done (sorry to look stupid, but have no general idea about how we could manage to get things compressed and uncompressed to where we want, as well as how to enable overlay ram: in pinforic there was a routine in page 4 we called to do so -don't remember the address now though-).

I have made a test and it seems Dbug is right: you can have, for example from $90 to $ff in zero page for your needs, as well as $00 to $50, if that area is not used either.

I have been translating more C code to asm, but keeping some things so I can perform tests easily. OSDK memory map shows I am using from $500 to $8ea9, so we have still some room here.

Finally, if you provide me the charset data I can prepare the bubble function so it uses it instead of the one in the ROM and try to make it leave a frame 3 pixels wide in black, to see text better, even if it is reduced to 7 chars width. Also I can add the triangle and use less lines (40 hires lines mean 8 text lines with our 5-heigth charset, which could be too much). I am currently using it for the problem with the lift (remember?). Now Helena asks for the level you want to access... :)

Oh, and once you have cleaned and tweaked the world map, Twilighte, I can prepare a new version of the editor where you could select two colors for ink scanlines, and convert the world file. BTW, if we are to use infoposts to access menu, passcode, change character or whatever, we might want to reduce the number of times it appears in Alpha. Not necessarily now, but we can think about it.

I also want to work on the inventory (at least the internal representation) and convert the character graphics you sent me. Also I am thinking on puzzles for the game, and have a few ideas already :twisted:

A final note: I won't have internet connection until next monday (long weekend!). Will try to work something during these days, but cannot promise... have a lot of personal plans :)

Cheers.
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte »

Fully Tested on Euphoric (Compiles to about 1.2K):)

Code: Select all

;A suite of routines to display byte alligned 6x5 pixel characters on
;HIRES screen.
;place_char       - Relocate cursor and print Character (ASCII)
;       X       X position on screen (Byte alligned 0 to 39)
;       Y       Y position on screen (Row alligned 0 to 195)
;       A       Character Code (ASCII 32-122)
;       All Registers & Carry corrupted

;put_char         - Print Character(ASCII)
;       A       Character Code (ASCII 32-122)
;       Register A & Carry corrupted

;put_code         - Print Character(32-122), Carriage return(13) or Colour(0-7)
;                   or colour combo (See *1 below)
;       A       Character Code (ASCII)
;       Register A & Carry corrupted

;perform_CRLF     - Perform CRLF (Relies on last cursor relocation)
;       Register A & Carry corrupted

;put_colour       - Print Single Colour
;       A       Ink Colour(0-7)
;       Register A & Carry corrupted

;put_colour_combo - Print Colour Combination (2)
;       colour_0 First colour(0-7)
;       colour_1 Second colour(0-7)
;       Register A & Carry Corrupted

;relocate_cursor  - Relocate the HIRES cursor
;       X       X position on screen (Byte alligned 0 to 39)
;       Y       Y position on screen (Row alligned 0 to 195)
;       All Registers & Carry corrupted

;*1
;For sending colour combo, the byte sent in A is composed as follows
;B0-2 Colour 0
;B4-6 Colour 1
;B7 Set to 1(128)
;So to set colour combo 6 and 2, you would pass 128+(2*16)+6 (166)

;Translate Ascii to Character code
;This translates the following valid ascii values to character codes...
;32 Space
;33 !
;36 $
;38 &
;40 (
;41 )
;44 ,
;46 .
;48-57 0-9
;58 :
;59 ;
;63 ?
;65-90 A-Z
;97-122 a-z
;If a non-supported ascii code is sent in the range 32-63, then a ! will be
;shown.
#define HIRES   $ec33

 .zero
*=$00
screen          .dsb 2
Cursor_origin_x .dsb 1
Cursor_origin_y .dsb 1
temp_01         .dsb 1
reserved_x      .dsb 1
reserved_y      .dsb 1

 .text

;// Cut From Here //
;Test program - Cut this out when using code
;Display the text in table1 on 5 text rows including CR and colour changes
*=$500
test_driver
        jsr HIRES
        ldx #5
        ldy #10
        jsr relocate_cursor
        ldx #00
.(
loop1   lda table1,x
        pha
        jsr put_code
        inx
        pla
        cmp #"."
        bne loop1
.)
        rts

table1
 .byt 2
 .byt "This is a test to see how well"
 .byt 13,3
 .byt "my routine copes with chars &"
 .byt 13,7
 .byt "colours like"
 .byt 1
 .byt "this, and"
 .byt 13,166
 .byt "punctuation like () !?$ Etc."

ylocl
 .byt $00,$28,$50,$78,$A0,$C8,$F0,$18,$40,$68,$90,$B8,$E0,$08,$30,$58,$80,$A8,$D0,$F8,$20,$48,$70,$98,$C0,$E8,$10,$38,$60,$88,$B0,$D8
 .byt $00,$28,$50,$78,$A0,$C8,$F0,$18,$40,$68,$90,$B8,$E0,$08,$30,$58,$80,$A8,$D0,$F8,$20,$48,$70,$98,$C0,$E8,$10,$38,$60,$88,$B0,$D8
 .byt $00,$28,$50,$78,$A0,$C8,$F0,$18,$40,$68,$90,$B8,$E0,$08,$30,$58,$80,$A8,$D0,$F8,$20,$48,$70,$98,$C0,$E8,$10,$38,$60,$88,$B0,$D8
 .byt $00,$28,$50,$78,$A0,$C8,$F0,$18,$40,$68,$90,$B8,$E0,$08,$30,$58,$80,$A8,$D0,$F8,$20,$48,$70,$98,$C0,$E8,$10,$38,$60,$88,$B0,$D8
 .byt $00,$28,$50,$78,$A0,$C8,$F0,$18,$40,$68,$90,$B8,$E0,$08,$30,$58,$80,$A8,$D0,$F8,$20,$48,$70,$98,$C0,$E8,$10,$38,$60,$88,$B0,$D8
 .byt $00,$28,$50,$78,$A0,$C8,$F0,$18,$40,$68,$90,$B8,$E0,$08,$30,$58,$80,$A8,$D0,$F8,$20,$48,$70,$98,$C0,$E8,$10,$38,$60,$88,$B0,$D8
 .byt $00,$28,$50,$78,$A0,$C8,$F0,$18
yloch
 .byt $A0,$A0,$A0,$A0,$A0,$A0,$A0,$A1,$A1,$A1,$A1,$A1,$A1,$A2,$A2,$A2,$A2,$A2,$A2,$A2,$A3,$A3,$A3,$A3,$A3,$A3,$A4,$A4,$A4,$A4,$A4,$A4
 .byt $A5,$A5,$A5,$A5,$A5,$A5,$A5,$A6,$A6,$A6,$A6,$A6,$A6,$A7,$A7,$A7,$A7,$A7,$A7,$A7,$A8,$A8,$A8,$A8,$A8,$A8,$A9,$A9,$A9,$A9,$A9,$A9
 .byt $AA,$AA,$AA,$AA,$AA,$AA,$AA,$AB,$AB,$AB,$AB,$AB,$AB,$AC,$AC,$AC,$AC,$AC,$AC,$AC,$AD,$AD,$AD,$AD,$AD,$AD,$AE,$AE,$AE,$AE,$AE,$AE
 .byt $AF,$AF,$AF,$AF,$AF,$AF,$AF,$B0,$B0,$B0,$B0,$B0,$B0,$B1,$B1,$B1,$B1,$B1,$B1,$B1,$B2,$B2,$B2,$B2,$B2,$B2,$B3,$B3,$B3,$B3,$B3,$B3
 .byt $B4,$B4,$B4,$B4,$B4,$B4,$B4,$B5,$B5,$B5,$B5,$B5,$B5,$B6,$B6,$B6,$B6,$B6,$B6,$B6,$B7,$B7,$B7,$B7,$B7,$B7,$B8,$B8,$B8,$B8,$B8,$B8
 .byt $B9,$B9,$B9,$B9,$B9,$B9,$B9,$BA,$BA,$BA,$BA,$BA,$BA,$BB,$BB,$BB,$BB,$BB,$BB,$BB,$BC,$BC,$BC,$BC,$BC,$BC,$BD,$BD,$BD,$BD,$BD,$BD
 .byt $BE,$BE,$BE,$BE,$BE,$BE,$BE,$BF

;//To Here//

ascii2code
        cmp #97
.(
        bcs skip1
        cmp #65
        bcs skip2
        sbc #32
        stx temp_01
        tax
        lda punctuation_ascii,x ;31 Bytes
        ldx temp_01
        rts
skip1   sbc #97
        rts
skip2   sbc #39
.)
        rts
punctuation_ascii
 .byt 64,64,64,65,64,62,64,66,67,64,64,69,64,68,64,61
 ;    !  "  #  $  %  &  '  (  )  *  +  ,  -  .  /  0
 .byt 52,53,54,55,56,57,58,59,60,71,70,64,64,64,63
 ;    1  2  3  4  5  6  7  8  9  :  ;  <  =  >  ?


;Perform $CRLF
perform_CRLF
        stx reserved_x
        sty reserved_y
        lda Cursor_origin_y
        clc
        adc #06 ;Vertical character spacing
        tay
        ldx Cursor_origin_x
        jsr relocate_cursor
        ldx reserved_x
        ldy reserved_y
        rts


;Relocate Cursor
;Pass:
;X X position on screen (Byte alligned 0 to 39)
;Y Y position on screen (Row alligned 0 to 195)
relocate_cursor
        pha
        ;Calculate screen loc
        stx Cursor_origin_x
        sty Cursor_origin_y
        txa
        clc
        adc ylocl,y
        sta screen
        lda yloch,y
        adc #00
        sta screen+1
        pla
        rts

put_colcombo
        pha
        and #7
        sta colour_0
        pla
        lsr
        lsr
        lsr
        lsr
        and #7
        sta colour_1
        jmp put_colour_combo

;Print character, colour or Carriage return at next cursor position
;A Character Code
put_code
        cmp #128
        bcs put_colcombo
        cmp #13
        beq perform_CRLF
        bcc put_colour


;Print character at next cursor position
;A Character Code
put_char
        stx reserved_x
        sty reserved_y
        cmp #32
        beq put_space
        jsr ascii2code
        jsr put_char_direct
increment_cursor
        inc screen
.(
        bne skip1
        inc screen+1
skip1   ldx reserved_x
        ldy reserved_y
        rts
.)



put_space
        lda #64
;Places the colour in A at the current cursor position and increments the
;cursor.
;Pass:
;A Colour(0-7)
put_colour
        sta colour_0
        sta colour_1

;Places the colour combination of colour_0 and colour_1 at the current cursor
;position and increments the cursor.
;Pass:
;colour_0 The first colour (Repeated thrice)
;colour_1 The second colour (Repeated twice)
put_colour_combo
        stx reserved_x
        sty reserved_y
        lda colour_0
        ldx colour_1
        ldy #00
        sta (screen),y
        txa
        ldy #40
        sta (screen),y
        lda colour_0
        ldy #80
        sta (screen),y
        txa
        ldy #120
        sta (screen),y
        lda colour_0
        ldy #160
        sta (screen),y
        jmp increment_cursor


;Relocate cursor and Print character
;Pass:
;X X position on screen (Byte alligned 0 to 39)
;Y Y position on screen (Row alligned 0 to 195)
;A Character Code (ASCII)
place_char
        jsr relocate_cursor
        jsr ascii2code
put_char_direct
        tax     ;char_number
        lda character_bitmap_row0,x
        ldy #00
        sta (screen),y
        lda character_bitmap_row1,x
        ldy #40
        sta (screen),y
        lda character_bitmap_row2,x
        ldy #80
        sta (screen),y
        lda character_bitmap_row3,x
        ldy #120
        sta (screen),y
        lda character_bitmap_row4,x
        ldy #160
        sta (screen),y
        rts

;73 Characters + 7 for special chars (Not defined yet)
;80 Characters == 400($190) Bytes

character_bitmap_row0   ;80 Bytes
    .byt  $40,$70,$40,$46,$40,$5c,$7e,$70,$58,$4c,$58,$58,$40,$40,$40,$40
    .byt  $40,$40,$40,$44,$40,$40,$40,$40,$40,$40,$7e,$7e,$7e,$7e,$7e,$7e
    .byt  $7e,$72,$5c,$5c,$72,$5c,$7e,$7e,$7e,$7e,$7e,$7e,$7e,$7e,$72,$72
    .byt  $6a,$72,$72,$7e,$7c,$7c,$7e,$7c,$7e,$7e,$7e,$7e,$7e,$7e,$58,$7e
    .byt  $5c,$7e,$5c,$5c,$40,$40,$40,$40,$5f,$40,$40,$40,$40,$40,$40,$40
character_bitmap_row1   ;80 Bytes
    .byt  $5e,$7e,$5e,$7e,$5e,$50,$72,$7e,$40,$40,$5a,$58,$76,$7e,$5e,$7e
    .byt  $7e,$7e,$5e,$7e,$72,$72,$6a,$72,$72,$7e,$66,$72,$66,$66,$70,$70
    .byt  $60,$72,$5c,$5c,$72,$5c,$7e,$66,$72,$72,$72,$72,$70,$5c,$72,$72
    .byt  $6a,$72,$72,$74,$5c,$66,$66,$6c,$60,$60,$66,$72,$72,$72,$72,$72
    .byt  $5c,$68,$58,$4c,$40,$40,$4c,$4c,$53,$40,$40,$40,$40,$40,$40,$40
character_bitmap_row2   ;80 Bytes
    .byt  $66,$66,$66,$66,$66,$7e,$7e,$66,$58,$4c,$5c,$58,$7e,$66,$72,$72
    .byt  $72,$70,$78,$5c,$72,$72,$6a,$5e,$72,$6c,$7e,$7e,$60,$66,$7e,$7e
    .byt  $6e,$7e,$5c,$5c,$7c,$5c,$6a,$66,$72,$72,$72,$7c,$7e,$5c,$72,$72
    .byt  $6a,$5c,$7e,$48,$5c,$5c,$5e,$6c,$7e,$7e,$4c,$7e,$7e,$72,$5e,$4e
    .byt  $48,$7e,$58,$4c,$40,$40,$40,$40,$7c,$40,$40,$40,$40,$40,$40,$40
character_bitmap_row3   ;80 Bytes
    .byt  $66,$66,$60,$66,$78,$5c,$46,$66,$58,$4c,$56,$58,$6a,$66,$72,$7e
    .byt  $7e,$70,$4e,$5c,$72,$5c,$7e,$7c,$7e,$5a,$66,$72,$66,$66,$70,$70
    .byt  $66,$72,$5c,$5c,$66,$5c,$6a,$66,$72,$7e,$72,$66,$46,$5c,$72,$5c
    .byt  $7e,$66,$5c,$56,$5c,$72,$66,$7e,$46,$66,$4c,$66,$46,$72,$72,$40
    .byt  $40,$4a,$58,$4c,$4c,$4c,$4c,$4c,$53,$40,$40,$40,$40,$40,$40,$40
character_bitmap_row4   ;80 Bytes
    .byt  $7f,$7e,$7e,$7e,$7e,$5c,$7e,$66,$58,$5c,$56,$58,$6a,$66,$7e,$70
    .byt  $46,$70,$7c,$5c,$7e,$48,$5c,$66,$46,$7e,$66,$7e,$7e,$7e,$7e,$70
    .byt  $7e,$72,$5c,$7c,$66,$5e,$6a,$66,$7e,$70,$7f,$66,$7e,$5c,$7e,$48
    .byt  $5c,$66,$5c,$7e,$5c,$5e,$7e,$4c,$7e,$7e,$58,$7e,$7e,$7e,$7e,$4c
    .byt  $48,$7e,$5c,$5c,$4c,$46,$46,$40,$5f,$40,$40,$40,$40,$40,$40,$40

colour_0
 .byt 0
colour_1
 .byt 0

The demo can be got here...

http://www.defence-force.org/ftp/forum/ ... ntdemo.tap
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

Twilighte wrote:Fully Tested on Euphoric (Compiles to about 1.2K):)
Just tested it and it works very nicely! It has much more options than I expected. We have to use those wonderful color possibilites...

I will try to integrate it promptly on the working demo and use it to display things on screen and on bubbles to see the effect. If I understood correctly the function relocate_cursor gets the screen address to positions screen and screen+1... so it will be enough if I set those addresses from within the program to make it work in the bubbles... As I already have a pixel_address function (even if much more complicated than your approach, as it has to handle more things) we might save quite a lot of space.

On the other hand I have been converting your sprite graphics. It took me more than 2 hours (I am dumb and slow with graphics) but I have Koenig working and it looks very good! It took me some time to get used to how his heigth changes while walking, but it is much more natural this way. Will do the same with Helena and some other small details and post a new version soon.

Regards,
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Another advantage of using 'graphic' text, is that it is possible to use special codes to draw graphics in the text, like for example if you have a character that tell you that you need a key, it can be displayed like this:

"In order to open the door, you need the [magnetic key graphics] that you will find in the commander's room."
Post Reply