forum.defence-force.org

If you want to implement look ahead, you should take a look at game trees.

barnsey123 wrote:First poster in December. Yay.

Am sick of the sight of this bloody game but I'll finish it if it kills me.

LMAO!
Hang in there. Once it's done you won't mind so much.

Godzil wrote:There is no such things as "hardware sprite" on the Apple II, but the framebuffer is a bit easier to use than the Oric one

That interleaved memory mess on the Apple II is actually easier to use than one on something else? (keels over from shock)

Ah thanks indeed JamesD. I think this player may suit my needs. I am not sure if I will be able to write any music as AY register values, but I will certainly try. And it should also be suitable for the basic sfx. In fact I was tempted to make direct calls to the ROM sound routines (music) so a son...

Has anybody experimented with producing simple tunes in a compact way? Something like storing the note and the duration and a very small player... Don't need anything like it being interrupt driven or ornaments or effects... I posted assembly source to fairly simple assembly player here: http://for...

Since you are already using multiple sections, you could do a table per section, however many would bring the number of tiles down to 128 for a section. But then it wouldn't be very practical memory wise. And since it does scrolling you'd be scrolling the pointers through the screen tables as well a...

Come to think of it, if a screen only had 128 tiles and you don't have too many screens to fit in memory, you could just represent the screen as a table of pointers direct to your tiles. <edit> Actually, you wouldn't be limited to 128 tiles this way but you'd have to deal with crossing a page bounda...

If you have the memory space for it, you could have a table of pointers to your tiles. I guess multiple tables if different screens use different tiles. As long as only 128 tiles are used / screen anyway. Then you just need to multiply the tile number you are looking up by 2 (bit shift) and put it i...

Due to hardware differences the code would definitely be very different on the Oric, but things like AI might be usable if they are well enough commented.

BTW, I hear an occasional soft click in the first one but no ringing.

Your ears/brain must be picking up some sort of harmonic frequencies

I definitely hear the tik tik tik tik

Not hearing bells in the first one.

Hmmmm... 16K for the code + 7 other banks of 16K is 128K.
Porting could take a while.

The 6502 does not support the C language very well. C is very stack oriented and due to the small stack on the 6502, compilers have to maintain a separate stack... which is slow and large.

A C compiler with the capabilities of a good cross compiler would probably be larger than ORIC RAM. You'd need to split it up into sections and generate intermediate files between compilation stages. This method was used on several compilers back in the day and they were much more limited than today...