Space99 - Development Forum

Want to talks about games you like, would like to see developed on the Oric, it's here.
Post Reply
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Space99 - Development Forum

Post by Twilighte » Wed Jun 14, 2006 10:41 am

This is a development level forum for the sharing of information towards a new Isometric game with the working title of Space99.
Currently on the project is myself and Chema.

So Chema, can you please detail the format of Isometric blocks and perhaps tell me the different types you'd like to have, the maximum quantity of blocks, etc.
I will move onto Sprites later, just want to get some basic shapes displayed first to see how well they work.

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema » Wed Jun 14, 2006 6:45 pm

Sorry for the delay in the response... Did I mention I had very little spare time? :)

Ok. To answer some questions, let me try to summarize the important things.

What I would like is to recreate moonbase Alpha (at least part of it) from the old series Space:1999. I don't know if you are used to it, so let me point you out to some websites where you can find information on the series as well as images and photos of the main characters (which I would also like to recreate).

http://www.dasteph.com/alpha/files.html

http://www.space1999.net/~catacombs/cyb ... index.html


That should make a good start. Now onto graphics. NOISE works in rooms of 10x10 tiles, where (as walls are set on tiles in the borders) the normal walking area is 8x8. It also supports several heigths for stacked drawing with differences of 8 pixels, that is how I do things like puting a table and a lamp onto it, but also can be used to put decorations into walls (the number 1 that appears in some doors in the demo is an example).

Here you can find a file containing some of the next examples.

http://www.isa.uniovi.es/~chema/white+noise/blocks.zip

Also notice that it is not possible for now to put tiles on the floor. It is quicker this way, but this could change in a future. Of course you can put floor tiles if they are on different heights.

Currently I am using only 4 heights, as they take up space in memory (the room format is not optimized for space usage, but to be quick in collision detection) but this could be changed.

A standard block (that uses all the tile space and its height) is a picture of 24x20 (see block.bmp), but you can use much more higher graphics (I don't remember where the limit is, actually), for example for walls. Currently I am using images of 12x38 for walls, with the idea of them being 4 layers in height (8x4=32 logical coordinates). You can notice you don't need to draw the parts that would be occult, as NOISE correctly displays the tile.

Remember also that it can invert graphics on the fly, so I usually draw only one version (the one that corresponds to the upper and right walls). An example is panelU.bmp, but I also use pairs of graphics for some wall decorations and divide them in two parts. An example is ventanaA.bmp and ventanaB.bmp.

Of course you can draw walls with some "depth", like I use in doors. PuertaA.bmp is an example. Notice I am not pleased with doors as they are now. They are formed of 2 tiles for sides plus N tiles at height 4 (that is 32 in pixels) to make them sizeable, but that makes it impossible to put them in upper levels. Maybe a 2 tiles version (like they used in Filmation games) would do better, but they should be higher to avoid the sprite being painted incorrectly above the upper part of the door. This is another thing to work out...

The format I am using for walls now is AAUBBUCC, where U are panels of 1 tile (panelU.bmp) and AA, BB and CC are pairs of panels like windows or computers. Any combination can be stored with the current map format and they are reserved bits for special uses (for instance a wall all made of windows). Of course this could be changed.

For sprite sizes... remember collision detection is made at block level, so any character should be as "blocky" as possible to make it work well. There are some pre-defined sizes in NOISE, but it can be expanded easily (actually entering new values in an array). For example, a standard block, in logical coordinates, would have a size of 6x6x4 and a character is currently 5x5x12. In the file sizes.bmp you can see more examples.

WHITE currently animates characters of four frames and 18x34 pixels (see helena.bmp for an example). You'd need to draw them looking front and back, but remember again they are inverted on the fly, so only one picture looking to the player and right-side, and one back to the player and left-side of the screen (helenaback.bmp).

Finnaly (at last) stairs. It is becoming more tricky than I expected, but I will surely make it work. Stairs would be of block size and with 2 steps that carry the character from a level to the next (8 pixels above). Unfortunately I doubt we can make two levels, where the character could be below or above, because even if it is possible, there are not much more heigh layers free to put all the decorations.

However, an elevated place of 1 layer in height is possible, so it could be nice.

Ok, ok, maybe even more...

Did I forget something? Ah yes. NOISE can handle up to 63 (say 60 to be sure) different tiles for background pictures (tables, walls, lamps, objects...) *at the same time* (no problem to change some of them at runtime if you completely change your environment). Blocks that should not be sticked a tile (what I call "free" objects) can also be used, but with caution, as they take up more resources, so basically I'd leave them for moving characters, but could also be used for environment if necessary (a chair that could be pushed, for instance).

Too much information? Something missing? Just ask!

Regards,

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

Post by Twilighte » Fri Jun 16, 2006 12:39 am

Hi Chema, apologies for long delay, but both needed time to get my new system up and running (Dual TFT and new pc) and to absorb the format.

One big thing occurred to me.
In Space 1999 (Which i loved when it was on the tv) the set designs allow a diagonal wall, for example Dbug found this link...

http://www.space1999.net/~catacombs/cyb ... n1012.html

Would this be possible, or should i just use two Wall sections?

60 sounds a bit limited, though with the provision to mirror any wall (though You use the term invert) i am sure i can come up with some good designs.
Infact with Dbugs link u can easily take my walls and objects and map them.

In your original demo, exits front-left and front-right used a doorway. I would like to see Arrows instead like this...
Image
I can offcourse supply these extra graphics aswell
The reasoning behind this is that it will allow a large area to be split over several "Rooms" without a door in the middle of an area.
Back-Left/right exits will be more obvious.
would this be possible?
Also notice that it is not possible for now to put tiles on the floor. It is quicker this way, but this could change in a future.
That is a shame, would it be possible for this game?
It would be cool to use to have them because it is much easier to describe a room by its floor surface, ie. kitchen, toilet, hazardous areas, lounge, work room.

And before you say anything, i do realise we are talking 2:1 aspect.

here are some example graphics

Image

please let me know which you prefer? Ptoing (A good friend of mine who may be willing to help with sprites) suggested the bottom design.

You can also find the individual pics in this folder...

http://www.defence-force.org/ftp/forum/ ... 1999/walls

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema » Fri Jun 16, 2006 12:20 pm

Twilighte wrote:Hi Chema, apologies for long delay, but both needed time to get my new system up and running (Dual TFT and new pc) and to absorb the format.
Long delay? LOL You will see what *long* delay is by the time it will take me doing anything, for example stair climbing :)
Twilighte wrote:One big thing occurred to me.
In Space 1999 (Which i loved when it was on the tv) the set designs allow a diagonal wall, for example Dbug found this link...
http://www.space1999.net/~catacombs/cyb ... n1012.html

Would this be possible, or should i just use two Wall sections?
I knew the link, simply forgot to add it in the list :) Diagonal walls are possible, BUT for performance reasons collision detection routines check if a given tile is occupied or empty, so the effect won't be very beautiful... see what I meant with "restrictions" I added without noticing? This project was initially just to learn how isometric games were coded and I did not put much attention on that. Collision is better calculated with "free" objects, where it is performed by seeing if the two "bounding blocks" collide whatever is their position.

There are better strategies, but I fear they could be slower. Maybe we can put diagonal walls and see how they work, even with that restriction?

Maybe that is the reason why filmation games do not include that kind of walls in their games :)
Twilighte wrote:]60 sounds a bit limited, though with the provision to mirror any wall (though You use the term invert) i am sure i can come up with some good designs.
Infact with Dbugs link u can easily take my walls and objects and map them.
Sorry for using the wong term and confusing you. 60 should be more than enough for the game. I have collections of sprites of spectrum games and they use much less than that. Also memory is an issue, even if we could load graphics from disk if needed. Currently I am using a dozen or so. I know that limits quite much the quality of graphics, but it should work for this environment, where all the walls look similar. Decorations might be put to provide more variety. A wall is over 114 bytes plus the mask, 228. For 60 walls it would take over 13K of graphics, which I think should be more than enough!

My initial idea (may change now you have joined the team) was to provide something more oriented to interaction than anything else, where you could use different keys to open different doors, apparatus that may hack the computer, use an object onto another object to create a new one or perform some interesting action, take things and give them to other characters, etc. That will need extra memory...

Of course I planned to have two acting characters: Koenig and Helena, so you can manage them separately. We can have more, but 2 are already enough I think.
Twilighte wrote: In your original demo, exits front-left and front-right used a doorway. I would like to see Arrows instead like this...

I can offcourse supply these extra graphics aswell
The reasoning behind this is that it will allow a large area to be split over several "Rooms" without a door in the middle of an area.
Back-Left/right exits will be more obvious.
would this be possible?
You will then be happy to know that WHITE changes room whenever the character hits a border... well not really, but a little before. So you can have bigger rooms connected together without a problem. To avoid this behaviour an empty block with the SPECIAL bit set serves as a wall that is not-drawn (invisible), or maybe a special graphic with a line border or something may serve. Doors are simply around empty tiles, the character may walk over and pass to another room.

Of course this permits you to have rooms with different sizes/shapes. Obviously the character keeps the correct location when entering the new room.

The arrows may be put, but they will not be drawn by the engine, unless set up as tiles and managed correctly (phantom mode?).
Also notice that it is not possible for now to put tiles on the floor. It is quicker this way, but this could change in a future.
That is a shame, would it be possible for this game?
It would be cool to use to have them because it is much easier to describe a room by its floor surface, ie. kitchen, toilet, hazardous areas, lounge, work room.
I know it is a shame and am currently thinking about it. The problem is it will be slow, as tiles on the floor are rendered before the object layer (the rest) and requires another loop. I might have a look at this, because it will be a nice improvement. Something like just one tile type per room could serve, or we need more variety?

Maybe it is better to think we won't have them and, if it is possible and does not slow down the game itself, then implement the option.

This is quite interesting for me, as your point of view makes me realize the limitations and what should be implemented for NOISE 2.0 :) so feel free to point out any other aspect you feel as a limit or unnecessary.
And before you say anything, i do realise we are talking 2:1 aspect.

here are some example graphics

Image

please let me know which you prefer? Ptoing (A good friend of mine who may be willing to help with sprites) suggested the bottom design.
IMPRESSIVE! I also like the bottom desing more.

We can move onto more technical issues and maybe open another thread for discussing them? As I told you I have a problem with doors and stairs, and maybe we can discuss how to implement thigs, what should be (or not be) done, how anything could be improved... Even if some ideas are not implemented now, they can be in a future!

Regards,

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

Post by Twilighte » Fri Jun 16, 2006 2:04 pm

Long delay? LOL You will see what *long* delay is by the time it will take me doing anything, for example stair climbing
I was thinking about this last night (actually about 4 oclock this morning :) ). If the position of each sprite is calculated using some sort of X/Y/V table, would it be possible to "bend" this table to accomodate a slope instead of a staircase?
Maybe a little too ambitious, but me thinks a worthy suggestion.
A space station is more likely to have slopes than steps.
Maybe it is better to think we won't have them and, if it is possible and does not slow down the game itself, then implement the option.
That sounds ok for tiles.

As for doors, i can't remember whether Space1999 doors slide up or across. Either way i can create let us say 4 frames of animation as the door slides out of view. This would be a nice addition to the game.

What about a simple patterned floor across the complete complex, or perhaps a solid white permanent floor but not white screen?

As suggested by you and Ptoing, i will use the bottom design as the basis for the graphics in this game. Ptoing is a 2D graphic artist and i would like to bring him onto this project.
Atm he is in the process of changing jobs so is unavailable but he should be ready in a few weeks or so to do some sprite graphics.

I may alter the height to 39/40 instead of 38 for walls, since if you notice the heights of each 'light bar' in walls is not the same.

btw, i need to know what format of image you would ultimately like for walls and objects?
I have currently used png file format which is nice and small.

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema » Fri Jun 16, 2006 3:47 pm

I was thinking about this last night (actually about 4 oclock this morning :) ). If the position of each sprite is calculated using some sort of X/Y/V table, would it be possible to "bend" this table to accomodate a slope instead of a staircase?

Maybe a little too ambitious, but me thinks a worthy suggestion.
A space station is more likely to have slopes than steps.
In fact that is what I had in mind. It shouldn't be a problem to add both behaviours. Climbing up is very simple, as you only need to detect collision with the stair/ramp and, when this happnes, alter V accordingly (continuously for ramps -what continuous may mean when you have to go up 8 pixels in 6 steps- and every 3 collisions for stairs of two steps). That is working great now, even if there is a small variation as there are no collisions when the border of your sprite does not collide with a new tile. That is a normal behaviour if you think about it, except for stairs and ramps :) It gets more difficult as the character may collide with more than one tile at a time and a it can be partially on a stair and another tile. Also there could be other characters blocking his way so...

The problem is going down, because the character is now above the tile so there is not a collision.

One possibility I am exploring is checking which tiles are below the character (that is already done) at every step (or at every loop if you implement some kind of gravity), but it gets quite complicated to cover all the cases without heavy routines. It currently works partially, but there are some small problems I still have to solve (and have no idea about how to do so, being frank).
As for doors, i can't remember whether Space1999 doors slide up or across. Either way i can create let us say 4 frames of animation as the door slides out of view. This would be a nice addition to the game.
Across, if I remember correctly. That also was my idea, even if now I just made them dissappear. An animation would be very interesting.
What about a simple patterned floor across the complete complex, or perhaps a solid white permanent floor but not white screen?
Yes. That should do the trick. Also a solid floor could work, but anyway it would be made of tiles, so the programming is the same... or are you thinking about filling it up in a highly optmized way :) ?
As suggested by you and Ptoing, i will use the bottom design as the basis for the graphics in this game. Ptoing is a 2D graphic artist and i would like to bring him onto this project.
Atm he is in the process of changing jobs so is unavailable but he should be ready in a few weeks or so to do some sprite graphics.
Great.
I may alter the height to 39/40 instead of 38 for walls, since if you notice the heights of each 'light bar' in walls is not the same.

btw, i need to know what format of image you would ultimately like for walls and objects?
I have currently used png file format which is nice and small.
Perfect. Any format pictconv understands is ok for me, even if I used windows bitmaps.... hey! don't blame me! I am not a graphics man... :)

Regards,

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

Post by Twilighte » Sat Jun 17, 2006 8:35 pm

Dbug emphasised how cool it would be when the eagle ship is mapped so i spent last night doing it.
Here is the result...

Image

Please note only the main body of the ship has been sectioned off into "Walls". Perhaps we should use the term "Flats" since this is the same term as used on Stage sets and the word lends itself better to forming larger objects?
The eagle is also more than 10x10, even the one drawn.
I will section this drawing off into walls/Flats now.

I now need to get some objects done.
I will initially work on the following...

The commanders table
Workstations
Chairs
Round Table

Regards tiles and walls.
I had actually thought that 'back walls' and 'all floors' could potentially be held as a permanent background for the current screen. Any walls that sit infront should be mapped as objects and have masks etc.
By this method, worrying about floors should not be so much a problem, and might speed up the game since anything plotted on the screen must ORA with this image beforehand?

Also, do all walls/flats have to be same height in a single screen?
I assume Walls do not have associated masks, however in the two wall picture shown before, their is a required mask as the wall bends over itself as shown below and emphasised in red...

Image

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema » Mon Jun 19, 2006 11:51 am

Twilighte wrote:Dbug emphasised how cool it would be when the eagle ship is mapped so i spent last night doing it.
Here is the result...
[\quote]

That is impressive! I like that design a lot! We should use it, of course...
Please note only the main body of the ship has been sectioned off into "Walls". Perhaps we should use the term "Flats" since this is the same term as used on Stage sets and the word lends itself better to forming larger objects?
The eagle is also more than 10x10, even the one drawn.
I will section this drawing off into walls/Flats now.
The term "flats" is ok for me. It represents what we intend to do much better.
I now need to get some objects done.
I will initially work on the following...

The commanders table
Workstations
Chairs
Round Table
Perfect. Remember that they should be as reusable as possible, so we lower down the number of different graphics. Even if it is against better designs.
Regards tiles and walls.
I had actually thought that 'back walls' and 'all floors' could potentially be held as a permanent background for the current screen. Any walls that sit infront should be mapped as objects and have masks etc.
By this method, worrying about floors should not be so much a problem, and might speed up the game since anything plotted on the screen must ORA with this image beforehand?

Also, do all walls/flats have to be same height in a single screen?
I assume Walls do not have associated masks, however in the two wall picture shown before, their is a required mask as the wall bends over itself as shown below and emphasised in red...
I have had similar thoughts in the past, and is currently one thing I have in mind for next versions, as it would require rewritting some of the more low-level functions.

Anyway I "feel" that masks still will needed, as you pointed out, for most flats. That could explain why this is what they did in old filmation games in spectrum.

One good thing is that we can reuse a mask for several flats. In fact I only have one mask for all the flats in the demo, as long as they are variations of the same basic graphic. Maybe you would like to be able to see behind a window in some internal flats, and that would require a different mask, but I think we can make it all with 2-3 different masks.

Of course they do not need to be the same heigth at all, but they are all drawn at the same bottom position (depending on the layer they are in).

One important thing is that WHITE+NOISE are currently using (with all the needed buffers) over 10K of code (a bit more actually). This could increase, if we are to add ramps (still had no time to continue with this, but I will), floor tiles or more heights.

The map format uses 80 bytes for the rooms in the demo. Even if final rooms will be more complicated, we can assume we may have something as 3K for the map.

I am not able to give an approximation about how much space will take the game logic, but I am sure it will be quite large, which does not give us much space for graphics.

There are some memory areas we can use if needed, like the alternate charset (over 800 bytes).

I would love to keep the game working for 48K+tape machines, but, if needed, we can upgrade to disk configuration and make a similar trick we used in pinforic and get rid of DOS to directly access disk sectors and use the upper 16K for game data (for example graphics).

This would lead to being able to change the whole group of flats when entering new scenarios, but also a good use would be making the sprites of the main characters wear an space suit at some point. Just load the correct graphics in memory. Of coure, if it is possible to achieve the same effect just changing the pointer values to graphics, if we are able to keep all them in memory at the same time.

Ok, let's get back to work. This is going to be a hard month for me at the university...

Regards,

User avatar
TheSpider
Pilot Officer
Posts: 71
Joined: Sat Jan 07, 2006 8:17 am
Location: Lexington, Kentucky, USA (Ex-Elgin, Scotland)
Contact:

Spiders small Space 1999 contribution

Post by TheSpider » Mon Jun 19, 2006 1:13 pm

As a major Space 1999 fan, I have collected a few pictures over the years. Hope these help....

http://thespider.ath.cx/pics/Space-1999_Pictures/

http://thespider.ath.cx/pics/Space-1999_Wallpaper/
Peter (TheSpider) Paterson
A Scotsman in Kentucky
http://thespider.oric.org
http://mintspider.blogspot.com

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

Post by Twilighte » Mon Jun 19, 2006 11:17 pm

Perfect. Remember that they should be as reusable as possible, so we lower down the number of different graphics. Even if it is against better designs.
Space1999 graphics are relatively sparse. As far as i can see the following are the objects we'll need...

Partition flat (For top transparent walls in the laboratories)
Settee,Chair,Swivel Chair, beds
Round Table,rectangle table, Main mission table
Globe on pedestal,Control column
ornamental structures(2)
Items to carry
Eagle1 and other ships

The remaining graphics will be used for flats (Walls).
Having looked at alot more objects, i notice things like the main power unit control terminals and commanders table/chair are all black. This would be great to keep but whilst their is no floor available, high contrast graphics will be difficult to recreate.
One good thing is that we can reuse a mask for several flats. In fact I only have one mask for all the flats in the demo, as long as they are variations of the same basic graphic. Maybe you would like to be able to see behind a window in some internal flats, and that would require a different mask, but I think we can make it all with 2-3 different masks.

I must agree, most flats will be ok with one common mask (Which i can provide) otherwise we'll have memory problems.
In Space1999, most of the graphics will be flats, from the 'light' walls to the main power unit 'control' walls to the Eagle ships.
I would love to keep the game working for 48K+tape machines, but, if needed, we can upgrade to disk configuration and make a similar trick we used in pinforic and get rid of DOS to directly access disk sectors and use the upper 16K for game data (for example graphics).
Yes i agree, i would like this to be available on tap too. The trouble with using the upper 16K is that we'll need to write specialist routines to handle disc ops and in the past i have always found it better (easier) to limit to 48K.

Thanks Spider for the extra info, that may prove very useful as resource soon.

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

Post by Twilighte » Thu Jun 22, 2006 9:35 pm

Right, i have now uploaded all the walls (including masks) to here...

http://www.defence-force.org/ftp/forum/ ... 999/walls/

And their are also 3 objects (Commanders tables and Swivel chair) here...

http://www.defence-force.org/ftp/forum/ ... 9/objects/

User avatar
Steve M
Squad Leader
Posts: 533
Joined: Fri Mar 24, 2006 3:33 am
Location: Cumbria, UK
Contact:

Space 1999

Post by Steve M » Fri Jun 23, 2006 12:51 am

You may recall that Henrik Holm was working on this and got quite a lot of graphic done. IIRC he used HIDE.
I think he had converted some of the key sounds and had the basics ready but not the proper program started.

It would seem sensible to combine with his efforts and see if something can be completed.

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema » Fri Jun 23, 2006 10:14 am

Twilighte wrote:Right, i have now uploaded all the walls (including masks) to here...

http://www.defence-force.org/ftp/forum/ ... 999/walls/

And their are also 3 objects (Commanders tables and Swivel chair) here...

http://www.defence-force.org/ftp/forum/ ... 9/objects/
Ah excellent. Your designs are very good. I will have to split objects in to parts, as they should be at most as big as a tile, but that should be no problem.

Do you want me to include them in a test room, or you want to draw any of the well-known rooms using those flats to see if they work?

I have also a first quick and dirty version of the code that makes characters climb up/down stairs. It is just a proof of concept, but should be ready very soon. It also includes a very simple approximation to gravity.

I am still using stairs because I noticed that there are quite a few in Space:1999 sets, like in the division between Main Mission and the Command room.
You may recall that Henrik Holm was working on this and got quite a lot of graphic done. IIRC he used HIDE.
I think he had converted some of the key sounds and had the basics ready but not the proper program started.

It would seem sensible to combine with his efforts and see if something can be completed.
I had no idea about this... Was he working on a Space:1999 game? Then surely he may have some excellent ideas (I am thinking about those sounds :))

Regards,

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

Post by Twilighte » Fri Jun 23, 2006 8:14 pm

You may recall that Henrik Holm was working on this and got quite a lot of graphic done. IIRC he used HIDE.
hehe, love it when people use my software. ;)
I think he had converted some of the key sounds and had the basics ready but not the proper program started.
hmmm, i'll have to look into this, i have a vague memory that he sent me his work thus far a few years back.
Ah excellent. Your designs are very good. I will have to split objects in to parts, as they should be at most as big as a tile, but that should be no problem.
Damn, forgot about that rule. I can see the benefit in the code of keeping objects same size. However, having the flexibility of different sized objects would be cool, and was what my engine was being based on.
I had moved into storing the observed width and depth to calculate when a sprite could move behind or infront or beside an object. This was used for collision too. It was limited to rectangular objects only though.
The format is better illustrated below...

Image
Do/Wo/Ho was the Observed isometric dimensions
Hp/Wp was the Physical dimensions of the memory block.
GG Offset was the physical byte offset from origin to top left memory block.
Do you want me to include them in a test room, or you want to draw any of the well-known rooms using those flats to see if they work?
I have already tested them in the above examples, but it would be really cool to try them in a test screen.
I'd also like to know whose job it will be to map everything. I'm suspecting you'd like the job and thats fine, just need to know.
I have also a first quick and dirty version of the code that makes characters climb up/down stairs. It is just a proof of concept, but should be ready very soon. It also includes a very simple approximation to gravity.


wowow, i can't wait.
I am still using stairs because I noticed that there are quite a few in Space:1999 sets, like in the division between Main Mission and the Command room.
yep, that's a good point, however the height of the levels are a fraction of a full room height in Space1999.

I'll work on some more objects now.

User avatar
Chema
Game master
Posts: 2480
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema » Mon Jun 26, 2006 10:14 am

Greetings,

Just a quick note, so you know I'm still alive. I have been really busy these days (today one student I am tutoring is presenting her PhD...) so no advances :(
Damn, forgot about that rule. I can see the benefit in the code of keeping objects same size. However, having the flexibility of different sized objects would be cool, and was what my engine was being based on.
I had moved into storing the observed width and depth to calculate when a sprite could move behind or infront or beside an object. This was used for collision too. It was limited to rectangular objects only though.
The format is better illustrated below...
It is very similar to what I currently have. In fact what I have is two kind of blocks:
- Tiled, which occupy a tile and are bound to that position. Collision detection is done at tile level (if code is not zero, then there is something there) and, due to some limitations, they cannot extend further in width but they can in heigth, like our flats. They are very quickly to render and there are nearly no slowdowns if you have many around.

- Free objects, which may not occupy a tile and are not bound to them. They can be of different sizes (defined in an array so easily extensible). Collision detection with these objects is done with their bounding 3D box, first check if their "shadows" (rectangles on the floor level) intersect, then if positive, check if heights intersect. It is quite quick also, but of course not as fast as with tiled objects, as they should be checked at every move. I store their data in a similar way than yours, but graphic data (pointers to graphics and shadows and sizes) is in a separate structure than their 3D data (x,y,z coords and another byte which controls mirroring, special bit and automatic movement).

Problem with the latter is that the more you have, the slower the program. I thought about putting "ornaments" and pickable objects as tiled, and characters and other objects that may move or have different sizes, as free objects. This way you could, for example, push a chair or a table.

One limitation I entered nearly without noticing (again) is than when moving these objects and checking the tiles they are occupying it is supposed that their size is never greater than a tile in x,y... This could be fixed, I suppose, but I don't recall if it could lead to major changes in the core engine.

This kind of things arise at the surface when *using* the engine, that is why I wanted to do a small demo/game... to create a list of fixes for NOISE 2.0 :)
I have already tested them in the above examples, but it would be really cool to try them in a test screen.
I'd also like to know whose job it will be to map everything. I'm suspecting you'd like the job and thats fine, just need to know.
Now that you mention it :) Maybe your skills would be of great help here. I already have a separate function that loads a room in map with a given format and an external DOS program that takes an easier definition file for the map and "compiles" it to the internal format. As this format may change with your new graphics, it could be a great idea if you map everything and work on a new mapload function. It should be very easy and we can work together to some extent. I can provide the current format and code (as an example) and tell you what should be done in the function, how the array is filled-up with room data and so. Also I could prepare a small testing version so you can see rooms and move around.

Of course, unless you don't want to lose time with this and concentrate on graphics :)
Quote:
I have also a first quick and dirty version of the code that makes characters climb up/down stairs. It is just a proof of concept, but should be ready very soon. It also includes a very simple approximation to gravity.


wowow, i can't wait.

Quote:
I am still using stairs because I noticed that there are quite a few in Space:1999 sets, like in the division between Main Mission and the Command room.


yep, that's a good point, however the height of the levels are a fraction of a full room height in Space1999.
Don't expect too much, as what I did is very limited and basic yet. The height of the levels are indeed a fraction of a full room heigth, and that is what I am testing now... just stairs that (with two steps) rise your character one layer (8 pixels). When the char collides with a stair in the correct direction, it is moved up 4 pixels, before performing the horizontal movement. At another position it is moved 4 pixels again to gain the full heigth. A similar action is done when going down, even if checks are a bit different.

Gravity is not *real* yet, as it is implemented as "when your character is not at z=0 and not over a tile, it is moved down until hitting a tile or z=0". This is done currently on a single loop, so no movements in parallel from other characters. I know it is very basic, but it serves for going donwstairs and other small effects and I think we don't need anything more complicated, as we are not creating a platform game... are we?

That should work quite well for this demo and can be easily extended to higher heigths if you put staris together, allways with the limitation in layers I already told you (and which is something to reconsider, I know).

I have, btw, detected other small bugs I have to deal with and have a small optimization in mind (nothing exciting, but will serve to solve a couple of small details).

Will work more on this during the week (I suppose).

Oh, and we have to talk about doors. They seem innocent and easy, but are not indeeed!

Regards,

Post Reply