OType

[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!

[Twilighte]

Just an illusion.. aaahhh

[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

[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.

[Dbug]

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.

[Twilighte]

yep, agreed, i stand corrected.

[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

[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.

[Xeron]

Wow! That looks fantastic!

[ibisum]

I am blown away with anticipation. Cannot wait to play this! WOW!

[Antiriad2097]

As a static screenshot, its certainly looking interesting. How long until we get some preview video?

[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

[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).

[Chema]

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

[Twilighte]

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.

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..

Code: Select all

ADC #00
BVS FoundEmbeddedCode

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.