OType

Want to talks about games you like, would like to see developed on the Oric, it's here.
User avatar
ibisum
Squad Leader
Posts: 861
Joined: Fri Apr 03, 2009 8:56 am

Post by ibisum » Tue Feb 15, 2011 9:58 am

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! :)

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

Post by Twilighte » Tue Feb 15, 2011 10:51 pm

Just an illusion.. aaahhh ;)

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

Post by Dbug » Tue Feb 15, 2011 11:01 pm

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 :)

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

Post by Twilighte » Sat Feb 19, 2011 10:45 am

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.

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

Post by Dbug » Sat Feb 19, 2011 12:00 pm

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.

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

Post by Twilighte » Thu Mar 03, 2011 2:20 pm

yep, agreed, i stand corrected.

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

Post by Twilighte » Sun Mar 06, 2011 10:39 pm

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

Image

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

Post by Twilighte » Sun Mar 20, 2011 9:10 pm

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

Image

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.

User avatar
Xeron
Emulation expert
Posts: 382
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Post by Xeron » Sun Mar 20, 2011 9:11 pm

Wow! That looks fantastic!

User avatar
ibisum
Squad Leader
Posts: 861
Joined: Fri Apr 03, 2009 8:56 am

Post by ibisum » Mon Mar 21, 2011 9:50 am

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

Antiriad2097
Flying Officer
Posts: 148
Joined: Tue May 09, 2006 9:42 pm
Location: Aberdeen, UK
Contact:

Post by Antiriad2097 » Mon Mar 21, 2011 8:59 pm

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

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

Post by Twilighte » Tue Mar 22, 2011 12:53 am

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

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

Post by Twilighte » Mon Mar 28, 2011 1:29 pm

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

Image

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

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

Post by Chema » Tue Mar 29, 2011 5:20 pm

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 :)

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

Post by Twilighte » Tue Mar 29, 2011 6:33 pm

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 :twisted:

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 :P

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

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests