Page 3 of 6
Posted: Tue Feb 15, 2011 9:58 am
by ibisum
I am continuously blown away by the quality of these graphics .. never in my teenage life did I imagine that there would be the possibility for such rich, detailed use of color on the Oric-1.
I was always fighting with attribute clashing and hated it as a kid, envious of the per-pixel color capabilities of the Amstrad and C64 (well, sprites) and so on .. now you're showing me that I simply wasn't dealing with the issue properly, as a teenager, that my rage was ill-placed and if I'd thought about it a little more I probably would have been very, very happy with the results attainable through careful placement of those color-set and inverse attributes.
I sure am happy now, thats for certain!
Posted: Tue Feb 15, 2011 10:51 pm
by Twilighte
Just an illusion.. aaahhh 
Posted: Tue Feb 15, 2011 11:01 pm
by Dbug
That's the rewarding thing with the Oric: It's much more difficult to get something nice, but when you manage, you know you did something that only few brave souls would have managed to do
Posted: Sat Feb 19, 2011 10:45 am
by Twilighte
Lots of work done but only slight visual change. The score panel was 7 digits long, but to maximise bcd (Binary coded decimal) its now 8 digits long, and can therefore represent 99,999,999.
BCD is a way of storing decimal numbers in 8 bit bytes and is supported by the 6502 processor. One can set BCD mode and from then on all addition and subtraction operations act on the BCD formatted byte.
I'll leave it to others (and books) to discuss further but it makes it alot easier and quicker to calculate and display scores.
Posted: Sat Feb 19, 2011 12:00 pm
by Dbug
Twilighte wrote:BCD is a way of storing decimal numbers in 8 bit bytes and is supported by the 6502 processor [...] it makes it a lot easier and quicker to calculate and display scores.
I don't think it changes anything to the calculation performance, but for displaying scores it's indeed a lot better because all you need is a dump routine as such one used to display hexadecimal values.
Posted: Thu Mar 03, 2011 2:20 pm
by Twilighte
yep, agreed, i stand corrected.
Posted: Sun Mar 06, 2011 10:39 pm
by Twilighte
ok, managed to get game screen booting and fading in scorepanel. Not particularly smooth atm but its work in progress. However now at stage where everything is working, i can checkin project and start getting the actual game into some sort of working order :p
Scorepanel for first scene/level
Posted: Sun Mar 20, 2011 9:10 pm
by Twilighte
Ok, a little progress tonight. I've rewritten the sprite engine (making the handling of players much faster. The screen below shows the jeep as it will appear in the first scene (first game).
Its too high up but at least the sprite engine is now working
Now have to get the key read working to control the jeep for each player.
Posted: Sun Mar 20, 2011 9:11 pm
by Xeron
Wow! That looks fantastic!
Posted: Mon Mar 21, 2011 9:50 am
by ibisum
I am blown away with anticipation. Cannot wait to play this! WOW!
Posted: Mon Mar 21, 2011 8:59 pm
by Antiriad2097
As a static screenshot, its certainly looking interesting. How long until we get some preview video?
Posted: Tue Mar 22, 2011 12:53 am
by Twilighte
I incorperated the irq routine to read the keyboard and eventually play sfx and in-game music (if cpu time permits). Having problems detecting correct keys atm but when i do get this working i may very well provide a short vid
Its actually proving the playerfile works aswell.
Memory at the moment looks like this
Code: Select all
0000-00FF Zero page (will shift some code here later)
0100-01FF Stack
0200-02FF Not used atm
0300-03FF I/O
0400-9FFF Game code
A000-BFDF HIRES
BFE0-BFFF Not used atm
C000-FBFF Game Library and buffers
FC00-FDFF Playerfile (keys, name, level, etc)
FE00-FFFB Disk routines
FFFC-FFFF System vectors
Posted: Mon Mar 28, 2011 1:29 pm
by Twilighte
I'm now grappling with collision maps and routines and improving the precision and allignment of the other memory maps to them. For example the original screen height was 136 rows but this is not divisable by 6 which is the cell height for the Collision map. So the new maps look like this...
For the road to airfield i am considering using embedded codes in the graphics to indicate rough terrain, road verges and serious collisions
Embedded codes are like ascii codes 8 to 11, 13 to 15 and 24 to 25. They are not used in HIRES and are shown in black like code 64.
I used embedded codes in Pulsoids many moons ago for the bonuses.
Embedding codes sometimes makes it easier and more precise than collision maps to detect collisions.
For example in the road to airfield we need to detect left and right verges (road edges), rough ground and collisions such as trees, houses and garages.
Code: Select all
08 Rough ground
09 Left Verge
0A Right Verge
0B Collision
These are actually all the hidden codes i can find i can use in the graphic scheme.
We also need to know when the Jeep reaches a refuelling point.
This is done twofold. We detect the map we are currently updating (or the one before) is Garage and check for right verge then we can be sure the jeep is up for refuelling (The jeep will be reset to left verge on exiting this bit).
Posted: Tue Mar 29, 2011 5:20 pm
by Chema
Twilighte wrote:
For the road to airfield i am considering using embedded codes in the graphics to indicate rough terrain, road verges and serious collisions
Embedded codes are like ascii codes 8 to 11, 13 to 15 and 24 to 25. They are not used in HIRES and are shown in black like code 64.
I used embedded codes in Pulsoids many moons ago for the bonuses.
Embedding codes sometimes makes it easier and more precise than collision maps to detect collisions.
This is very smart, Twilighte. So they are actually attributes which are displayed as paper color? Very interesting. I guess, this could be an issue if you want to mask something against them, but I guess (as they are to detect collisions) that such thing never happens...
Great
Posted: Tue Mar 29, 2011 6:33 pm
by Twilighte
Chema wrote:This is very smart, Twilighte. So they are actually attributes which are displayed as paper color?
Sort of, there are codes that are redundant under HIRES and these appear as blank (or black) screen bytes.
08 in text mode sets LORES0 (or standard) character set, 09 sets LORES1 (or Alternate) character set, 0A sets standard double height and 0B sets alternate Double height. Since these codes are only relevant in TEXT mode they have no meaning in HIRES.
Chema wrote:I guess, this could be an issue if you want to mask something against them, but I guess (as they are to detect collisions) that such thing never happens...
Not at all, it requires some extra code in the Sprite plotting routine, code that would have to exist anyway to pick up the collision
Code: Select all
lda #00
sta EmbeddedCode
pswm_offset1
ldy $DEAD,x
lda (screen),y
bmi pswm_ProcInversedByte
cmp #64
bcc FoundEmbeddedCode
pswm_mask1
and $dead,x
pswm_bitmap1
ora $dead,x
...
FoundEmbeddedCode
and #3
sta EmbeddedCode
lda #64
jmp pswm_bitmap1
The above is a very simple example since it will only 'deliver' a single embedded code result at the end of the routine. I also only provide the 'essential' part of the code to simplify things.
All values below 64 are treated as embedded codes since i do not use Paper, ink or any other attributes in the map graphics (all down left hand side in AIC mode).
I explored branching on the overflow flag instead of comparing but this would still require the same number of cycles to branch..
The FoundEmbeddedCode routine resets the code to 64 for its visual bitmap equivalent before branching back to ORA with the bitmap. Its pointless masking with the AND before because its already an empty bitmap.
Its also possible to repeat the same branch for Inversed embedded codes and i intend to add this later
I also notice its also possible to include ink colour 6 on the cyan rows in the graphic background. this would mean 5 embedded codes (AND #7).
As mentioned before we could also use codes 32 to 63 but they do set the left most pixel and for my purposes thats a bit too restrictive.
