Space99 - Development Forum
The door animation looks good but your character halts briefly while it opens even if you aren't right by the door yet. The character shouldn't pause until right next to the door.
Some other comments...
It would be easier to control the character with 4 directional keys or a joystick but then you have to decide what to do when a person presses two directions at a time.
The animation is faster than I was expecting. With a little optimization it should run just fine on real hardware.
The action adventure idea sounds great and the balloon text boxes sounds cool. Have a look at the character interaction on Playstation or Nintendo games. The PS1 games like Final Fantasy did a pretty good job mixing text and graphics. I'd suggest looking at Final Fantasy 9... and no I don't expect the graphics to look that good.
Some other comments...
It would be easier to control the character with 4 directional keys or a joystick but then you have to decide what to do when a person presses two directions at a time.
The animation is faster than I was expecting. With a little optimization it should run just fine on real hardware.
The action adventure idea sounds great and the balloon text boxes sounds cool. Have a look at the character interaction on Playstation or Nintendo games. The PS1 games like Final Fantasy did a pretty good job mixing text and graphics. I'd suggest looking at Final Fantasy 9... and no I don't expect the graphics to look that good.
Hehe... yep. However this time we will be limited by memory constraints, so we might keep it simpler just to show what things could be done. Even with compressed text, don't expect too many different messagesDbug wrote: I totaly agree with that.
A good adventure game with lot's of dialogs and interactions
It is indeed a good idea (something like the Movie Spectrum game). It is surely possible, just a matter of drawing the bubble with text inside it, set the clip_rgn to cover the area and ask for redrawing for making it dissappear. What I feel is that there won't be enough space in the bubble as to put large texts (unless it is made HUGE) and I wonder how much code would be needed to implement it.What would be cool is to display the messages in bubles, like in cartoons, directly on top of the scene.
Would add a real adventure feeling I think.
Interested in writting such routine?
Then I suppose you are not interestedLot's of overtime too, girlfriend, christmas
Indeed. The door opens when you are "near it" and closes when nobody is "near it". The first "near" should mena righ next to it, which should work for upper walls, but do not for lower walls. That is a known problem about how graphics are displayed (already discussed in this thread) and I doubt we can do better than this. Everyting is stopped during animations. Even if the effect is not as good as I wish and could be corrected somehow (by calling white_loop between animation frames), this would mean there could be problems in some (extreme) cases with characters that move automatically.JamesD wrote:The door animation looks good but your character halts briefly while it opens even if you aren't right by the door yet. The character shouldn't pause until right next to the door.
Twilighte also stated so. It depends on your likings... I allways preferred this kind of control, but I suppose it shouldn't be difficult to add both to the final game.Some other comments...
It would be easier to control the character with 4 directional keys or a joystick but then you have to decide what to do when a person presses two directions at a time.
I allways test with the speed 1.0, to see how it goes, even if I double the emulation speed when I need to move around. Problem here is that it would be hard to optimize further (anyway we will try), but the real matter here is that some rooms are too complex (and so beautiful) and that, when there are other characters moving around, speed is divided by two for each character. Anyway I was sure it was quicker before, so I have to check some things..The animation is faster than I was expecting. With a little optimization it should run just fine on real hardware.
In simple rooms (with not many tiles) it is quite adequate. Still I am not sure if we could gain something by disabling interrupts.
Don't have Playstation or Nintendo, but will look around in the web. To be frank, I thought about using the three bottom lines of text for displaying messages and the empty area around the room graphic to display inventory, current active character and any other information about the game. Other variations may include using some place at the hires screen for displaying text and make a charset which is 6x6 to gain some space, but that means more programming and more codeThe action adventure idea sounds great and the balloon text boxes sounds cool. Have a look at the character interaction on Playstation or Nintendo games. The PS1 games like Final Fantasy did a pretty good job mixing text and graphics. I'd suggest looking at Final Fantasy 9... and no I don't expect the graphics to look that good.
And I would also want to have some kind of sound, of course. At least some effects, but I confess my inability in this field... worse than even with graphics, so I would need help.
Regards,
Need your oppinion.
I uploaded yet another version of the animated doors:
http://www.defence-force.org/ftp/forum/ ... doors2.zip
This time I removed some frames in the animation, leaving it only with the door closed/half open/open. It saves time and also tilecodes, which is something important.
Please test it and tell me what you think. If most of you like this and do not think more frames are needed, then I will proceed this way. If you prefer the older version, then I will revert the changes.
I also put back the buffer in "normal" memory. Notice now there are no halts while moving the character.
Let me know what you think, as I intend to convert code to asm as soon as possible, so we can proceed with the game.
I uploaded yet another version of the animated doors:
http://www.defence-force.org/ftp/forum/ ... doors2.zip
This time I removed some frames in the animation, leaving it only with the door closed/half open/open. It saves time and also tilecodes, which is something important.
Please test it and tell me what you think. If most of you like this and do not think more frames are needed, then I will proceed this way. If you prefer the older version, then I will revert the changes.
I also put back the buffer in "normal" memory. Notice now there are no halts while moving the character.
Let me know what you think, as I intend to convert code to asm as soon as possible, so we can proceed with the game.
Hi, i've just done a very rudamentary mockup design for the game.
Please feel free to give me some feedback.
I've also done some work on the map, as follows...
1) All Border Doors reach 'Border'.
2) All Lifts also reach border
3) Only Surgery_door is used for interior doors
4) The previously mentioned spare tile changes have been implemented
Still have to redesign main mission and some other stuff.
Ooops, ftp connection is broken, i will try to upload tomorrow.
Please feel free to give me some feedback.
I've also done some work on the map, as follows...
1) All Border Doors reach 'Border'.
2) All Lifts also reach border
3) Only Surgery_door is used for interior doors
4) The previously mentioned spare tile changes have been implemented
Still have to redesign main mission and some other stuff.
Ooops, ftp connection is broken, i will try to upload tomorrow.
I just checked out the latest version.
I like the way the newer doors work. The game flows better with the faster doors.
I did some exploration around the layout and there are some things I ran across that I'd like to comment on.
There was a small room inside of another room and there wasn't enough wall to instantly convey that it was an inner room. It looked like a door with lines on the floor. Once you've seen it and figured it out you would easily recognize what it is if you see another one but I just thought the lines on the floor wasn't quite consistent with how the outside walls were displayed.
I walked the character off a platform and they slowly floated down to the lower level. I'd say cut the number of frames in the animation just like you did with the door. You don't want an instant drop but it definitely needs to be faster.
The speed the character walks at is slower than I think it should be for proper pacing of the game.
Twilighte, I like the looks of the mockup.
I like the way the newer doors work. The game flows better with the faster doors.
I did some exploration around the layout and there are some things I ran across that I'd like to comment on.
There was a small room inside of another room and there wasn't enough wall to instantly convey that it was an inner room. It looked like a door with lines on the floor. Once you've seen it and figured it out you would easily recognize what it is if you see another one but I just thought the lines on the floor wasn't quite consistent with how the outside walls were displayed.
I walked the character off a platform and they slowly floated down to the lower level. I'd say cut the number of frames in the animation just like you did with the door. You don't want an instant drop but it definitely needs to be faster.
The speed the character walks at is slower than I think it should be for proper pacing of the game.
Twilighte, I like the looks of the mockup.
Hi James, Nice to at least have somebody new with potentially new ideas
Thanks for the feedback
The Graphic for the inside column and even inside wall could potentially be made to look higher, the problem is that it may also look like a broken column or wall if not done right. The reason why the outside wall at the front doesn't look 'broken' is because it joins well with the back walls.
I hope you understand.
Thanks for the feedback
Yes,well their are two objects destined for internal walls. Because of the harsh constraint of 64 objects in the game, i have had to make quite a few compromises.There was a small room inside of another room and there wasn't enough wall to instantly convey that it was an inner room. It looked like a door with lines on the floor. Once you've seen it and figured it out you would easily recognize what it is if you see another one but I just thought the lines on the floor wasn't quite consistent with how the outside walls were displayed.
The Graphic for the inside column and even inside wall could potentially be made to look higher, the problem is that it may also look like a broken column or wall if not done right. The reason why the outside wall at the front doesn't look 'broken' is because it joins well with the back walls.
I hope you understand.
Greetings... let's go:
Problem I see is the size of the bottom graphic. Maybe it is now interesting to think about how overlay ram can be used. I am still using some rom functions (for displaying text, for entering hires mode, etc) and either we write them again or we will have to switch the rom back and forth. I f we do the latter intelligently, maybe there will be no problem.
Which areas of the overlay ram can be used without disrupting disk access? How can we proceed? Maybe load something into normal memory, then move it to overlay and then load the rest? I never did such a thing.
Does anyone know how many cycles might be lost for leaving interrupts enabled? I did not install any handler or did anything with them.
If you agree, Twiligthe, then I will change this. It would only take 1 extra tile for animating doors. I will do the same on lifts and see how it looks like.JamesD wrote:I just checked out the latest version.
I like the way the newer doors work. The game flows better with the faster doors.
I like it a lot. We have to be careful with putting anything on the upper corners, so highest graphics do not overlap with the design. I also have to change the way a room is shown, because I put all the upper part in black ink and then in the room color ink, instead of just the upper triangle. On the bottom it should work ok.Twilighte wrote:Hi, i've just done a very rudamentary mockup design for the game
Problem I see is the size of the bottom graphic. Maybe it is now interesting to think about how overlay ram can be used. I am still using some rom functions (for displaying text, for entering hires mode, etc) and either we write them again or we will have to switch the rom back and forth. I f we do the latter intelligently, maybe there will be no problem.
Which areas of the overlay ram can be used without disrupting disk access? How can we proceed? Maybe load something into normal memory, then move it to overlay and then load the rest? I never did such a thing.
You are right. In fact I added this "gravity" just for the purpose of going downstairs, never thought on the possibility of falling from a platform. I remmeber there was some kind of restriction which forced me to keep all the frames... I will give it a look again.I walked the character off a platform and they slowly floated down to the lower level. I'd say cut the number of frames in the animation just like you did with the door. You don't want an instant drop but it definitely needs to be faster.
This is more problematic. I have seen games from the old days where speed was more or less the same than here. In fact it gets slower when the background is more complex, and in Space:1999 it is complex. Blame having to rotate scans of 6 bits! Frankly speaking I can't see how to make this better.The speed the character walks at is slower than I think it should be for proper pacing of the game.
Does anyone know how many cycles might be lost for leaving interrupts enabled? I did not install any handler or did anything with them.
You cannot easily extract areas of the Overlay RAM for your own routines. It is better to write Disk access routines (or in my case get others to write them!!) in about 1K and then you'll have the other 15K to do what you will with.Which areas of the overlay ram can be used without disrupting disk access? How can we proceed? Maybe load something into normal memory, then move it to overlay and then load the rest? I never did such a thing.
Note that only on the disk system can you switch out the RAM without a hardware mod. So once we start using overlay, their is no easy way back to a tape game.
I disagree, This form of Oric graphics lose more on memory than on speed and may even prove faster than an equivalent machine.!This is more problematic. I have seen games from the old days where speed was more or less the same than here. In fact it gets slower when the background is more complex, and in Space:1999 it is complex. Blame having to rotate scans of 6 bits! Frankly speaking I can't see how to make this better.
By this time, Chemas eyebrows will have risen a few metres.
The reason for this is fairly simple.
A displayed byte on the Oric is 6 bits and on most other machines it is 8.
This means that displaying the same pixel area will take more time on the Oric than on the other 8 bit machine.
However rotating the graphics will take less because we have less bits to rotate into view.
I also believe you are not using the age old method of byte rotation which involves examining the rotation required prior to the rotation process.
If we need to rotate the graphic 2 bits to the left, we can call a routine to scroll left twice.
If we need to rotate the graphic 4 bits to the left, we can call a routine to scroll 2 bits to the right but with the destination set 1 byte to the left.
So if we are always scrolling 2,4 or even 6 bits, we can use two routines for scrolling two bits and don't need the 4 bit scroller (Which i can imagine would be very slow).
I used this method in the game Zip and Zap. Because of the simultaneous real sound samples i need to optimise the smooth scrolling sprites.
Since rotation of the graphic will take more cpu time than displaying the bytes, the Oric may be considered at least no slower than another machine.
However, unlike that other machine, the Oric will consume more bytes when storing the graphic. Because each displayed byte is only using 75% of its capacity.
Hehe, alot, but be careful. Disabling interrupts whilst still linking into ROM routines may damage the Orics healthDoes anyone know how many cycles might be lost for leaving interrupts enabled? I did not install any handler or did anything with them.
The ROM relies upon irq for timing and keyboard strobing events.
The best answer is to (yes) disable irq's with the SEI instruction but then to call our own routines to read from the keyboard and switch to HIRES.
Dbug has some nice routines to switch to HIRES and i can at some point provide some keyboard routines.
The keyboard routines are many and varied and all depend on the type of control you are looking for.
For example, for character entry, you will require a routine that observes key delay and even repeats and maybe ASCII characters returned.
For games, you may require configurable keys, 6 or more and the number of keys may make a difference to the way it is designed.
Obviously the more keys, the slower the routine but their are shortcuts.
Like in ZipnZap again, their is a period that must exist on the real oric between writing the keyboard row and reading back the key status(about 12 or more cycles i think). This delay was used to display a score digit
Tell me what you are wanting (James too please).
Please also note that even if you require a keyboard routine that emulates the Oric ROM routine, it will still be faster these days.
Back when men were real men, the oric ROM masters wrote very shitty code to do the job, but did not spend much time on speed optimisation.
I have done alot of work in this area and their are many shortcuts to reduce the time dramatically.
The original ROM routine scanned all 58 keys in one irq event, when you consider each key must use that 12 cycle delay, this soon adds up to a very slow routine.
Their is a way to strobe 8 keys at a time (in a single sta) which is a method i have often used for tight cpu requirements.
Infact ZipnZap again rings bells in my ears. that game used just 8 keys for the 2 player game. and the routines were extremely fast.
Back to the screens. I have also taken some time to design some Space:1999 Oric fonts. The first one is 7 high (I will explain later why using less than 8 high fonts on oric HIRES is better).
And here is the same but 5 high.
Just successfully uploaded white.rar at the usual location and with the amendments mentioned a couple of messages back.
Back when men were real men, the oric ROM masters wrote very shitty code to do the job, but did not spend much time on speed optimisation.
I have done alot of work in this area and their are many shortcuts to reduce the time dramatically.
The original ROM routine scanned all 58 keys in one irq event, when you consider each key must use that 12 cycle delay, this soon adds up to a very slow routine.
Their is a way to strobe 8 keys at a time (in a single sta) which is a method i have often used for tight cpu requirements.
Infact ZipnZap again rings bells in my ears. that game used just 8 keys for the 2 player game. and the routines were extremely fast.
Back to the screens. I have also taken some time to design some Space:1999 Oric fonts. The first one is 7 high (I will explain later why using less than 8 high fonts on oric HIRES is better).
And here is the same but 5 high.
Just successfully uploaded white.rar at the usual location and with the amendments mentioned a couple of messages back.
You definatly want to use your own keyscan routine and replace the interrupt handler with your own. You'll need to leave interrupts enabled just so they can be used as a simple timer if nothing else. They are also handy for playing music in the background.
I'm not sure about the ORIC but most 8 bit computers I've dealt with didn't use interrupts for disk access. They used polling. The CPUs were just too slow to do much else. I do worry about replacing the ROM disk routines with your own though. If someone comes up with an IDE or SD card interface it will probably include a custom ROM and you won't be able to access files directly unless they emulate the disk controller somehow. I've seen it done but it's more expensive.
Dump the cassette version. With such limited RAM you won't be able to put in much gameplay unless you can swap things in and out. Put as much in RAM as you can and then see where things stand when you run out of space. You could load different levels of the complex when you use the lifts if needed or blocks of dialog between characters. You could even add cut scenes to show the results of performing some action.
That font looks ok. The 2 on the 5 pixel high version needs some fixing.
I'd need to see a sample screen to see if it's readable enough.
Back to the sample screen graphic...
The light blue in the upper corners might be better in a different color. The dark blue might be better to convey the feeling of cold, dark space.
Just a thought.
I'm not sure about the ORIC but most 8 bit computers I've dealt with didn't use interrupts for disk access. They used polling. The CPUs were just too slow to do much else. I do worry about replacing the ROM disk routines with your own though. If someone comes up with an IDE or SD card interface it will probably include a custom ROM and you won't be able to access files directly unless they emulate the disk controller somehow. I've seen it done but it's more expensive.
Dump the cassette version. With such limited RAM you won't be able to put in much gameplay unless you can swap things in and out. Put as much in RAM as you can and then see where things stand when you run out of space. You could load different levels of the complex when you use the lifts if needed or blocks of dialog between characters. You could even add cut scenes to show the results of performing some action.
That font looks ok. The 2 on the 5 pixel high version needs some fixing.
I'd need to see a sample screen to see if it's readable enough.
Back to the sample screen graphic...
The light blue in the upper corners might be better in a different color. The dark blue might be better to convey the feeling of cold, dark space.
Just a thought.
James, you repeated your message three times!!
It may be an issue with the forum because as a consequence i got three email notifications, but only the first one has a message in it.
As for the IRQ routines, apart from key delays and music, their is no need for the irq routines. Delays can be got from using the spare 6522 timer.
Music is one aspect of Space:1999 that we haven't really thought about much. Music on the Oric is a pain, mainly due to a lack of good trackers (The only real one is my own and is a bit memory hungry and doesn't use all the features of the sound chip).
I can do the music (i can pretty much do most stuff on Oric) but it will take some time.
I wish we had SD or HD on the oric. People have done such an interface but unfortunately it was not done at a time that encouraged more than just a couple of them being produced. I think the only way we'd use that technology would be if ever it was cheap enough to release as part of the game!!
As i say this is only a mockup, the bottom section will be filled up with objects and text boxes. The top section will be for stats of the character you are controlling.
We could handle 4 characters, but i quite like the idea of two, like Head over Heels. You could survive with two. Koenig with his practical skills and Russel as the doc.
A new plot would be cool, perhaps all the other Alphans have been abducted by a strange alien race and it is left to just the two to get them back?
What do you think?
It may be an issue with the forum because as a consequence i got three email notifications, but only the first one has a message in it.
As for the IRQ routines, apart from key delays and music, their is no need for the irq routines. Delays can be got from using the spare 6522 timer.
Music is one aspect of Space:1999 that we haven't really thought about much. Music on the Oric is a pain, mainly due to a lack of good trackers (The only real one is my own and is a bit memory hungry and doesn't use all the features of the sound chip).
I can do the music (i can pretty much do most stuff on Oric) but it will take some time.
The Oric DD has two modes, polling and irq, both methods are valid.I'm not sure about the ORIC but most 8 bit computers I've dealt with didn't use interrupts for disk access. They used polling. The CPUs were just too slow to do much else. I do worry about replacing the ROM disk routines with your own though. If someone comes up with an IDE or SD card interface it will probably include a custom ROM and you won't be able to access files directly unless they emulate the disk controller somehow. I've seen it done but it's more expensive.
I wish we had SD or HD on the oric. People have done such an interface but unfortunately it was not done at a time that encouraged more than just a couple of them being produced. I think the only way we'd use that technology would be if ever it was cheap enough to release as part of the game!!
Yep, just saw that after uploadThe 2 on the 5 pixel high version needs some fixing
Yep, soon, soonI'd need to see a sample screen to see if it's readable enough
The light blue in the upper corners might be better in a different color. The dark blue might be better to convey the feeling of cold, dark space.
As i say this is only a mockup, the bottom section will be filled up with objects and text boxes. The top section will be for stats of the character you are controlling.
We could handle 4 characters, but i quite like the idea of two, like Head over Heels. You could survive with two. Koenig with his practical skills and Russel as the doc.
A new plot would be cool, perhaps all the other Alphans have been abducted by a strange alien race and it is left to just the two to get them back?
What do you think?
Right.. the reasons for less than 8 high font?
1) the less high the font the more lines can be displayed in the same graphic area.
2) the less high the font the less memory used by the font.
The font in the message before had 73 characters.
for 6x5 thats 365 bytes, 6x6 is 438, 6x7 is 511.
3) any character less than 8 high can be displayed using a very simple routine (if byte alligned).
Oh and one thing not noticed is that the 6x7 was infact 6x9. However each character is no more than 6x7 but some characters like lowercase j and g are offset 2 rows down. This sort of thing should not be a problem in the code. Infact the two top bits of the first byte in each character definition could hold the y offset.
Incidentally, the font was taken from here and redrawn by hand in euphoric using HIDE.
http://www.space1999.net/eagle/graphics/count.jpg
1) the less high the font the more lines can be displayed in the same graphic area.
2) the less high the font the less memory used by the font.
The font in the message before had 73 characters.
for 6x5 thats 365 bytes, 6x6 is 438, 6x7 is 511.
3) any character less than 8 high can be displayed using a very simple routine (if byte alligned).
Code: Select all
ldx #06
loop1 ldy screen_offset,x
lda character_bitmap,x
sta (screen),y
dex
bpl loop1
screen_offset
.byt 0,40,80,120,160,200,240
Oh and one thing not noticed is that the 6x7 was infact 6x9. However each character is no more than 6x7 but some characters like lowercase j and g are offset 2 rows down. This sort of thing should not be a problem in the code. Infact the two top bits of the first byte in each character definition could hold the y offset.
Incidentally, the font was taken from here and redrawn by hand in euphoric using HIDE.
http://www.space1999.net/eagle/graphics/count.jpg