Author Topic: OmniRPG - Coding (Read 67111 times)

willrandship · « **Reply #30 on:** December 08, 2012, 01:54:38 am »

You mean this one, right? http://www.ticalc.org/archives/files/fileinfo/421/42148.html

@Tr1p1ea I don't think it would be too much data, if you're just referring to storage space, since we'll be using external appvars for large parts of the storage. We could store most of the sprite data there. 8 lvl grey is a little excessive, though.

What if we made it 3 level gray, but only the background used the back layer? All sprite work would be done in monochrome, so everything but scrolling and updating the screen only works on one buffer, but we still get the pretty area maps and whatnot.

Sorunome · « **Reply #31 on:** December 08, 2012, 01:55:48 am »

yeah, exactly!

Xeda112358 · « **Reply #32 on:** December 08, 2012, 07:53:53 am »

So, I posted this in the sprites topic (this is something chickendude was working on):

Monochrome here looks pretty snazzy and I like the masking. If we kept it at 3 or 4 level gray, I am thinking each 16x16 sprite would be 128 bytes.

1 layer for masking
2 layers for the gray sprite
1 layer for collision detection

Because of this, monochrome is probably better and it will free up a buffer for collision detection .__.

Sorunome · « **Reply #33 on:** December 08, 2012, 12:51:31 pm »

that is looking actually pretty good. BUt wouldn't greyscale still be possible like that on 16MHZ?

stevon8ter · « **Reply #34 on:** December 08, 2012, 05:24:21 pm »

* 15MHZ...?

I guess it should be possible... But they're discussing if they would do something like auto detect MHZ so 15 = grey , 6= mono
Or something like user choice...

Xeda112358 · « **Reply #35 on:** December 08, 2012, 05:57:01 pm »

Yeah, I think there should be an option for grayscale. If you turn grayscale on, the calc will attempt to work at 15MHz. If you use monochrome, the calc will be put at 6MHz. If the calc is capable of 15MHz, it will start with grayscale by default.

Anyways, I started a little coding, just to get the idea flowing. It is actually being more of a pain than I thought it would be, especially because I am trying to make sure it is Axe compatible

I also used some simple sprites and a simple tilemap to test the engine, currently (it only shifts left or right and I removed the code to check for the edge of the map). It allows for variable sized tilemaps as well, and it can start at different offsets into the tilemap

EDIT:
In the main topic, we have been discussing using Matrefeytontias' Axiom that will allow us to access routines in apps (so kind of like a shell). Since this project will be big and we can program in some highly optimised routines in an app, I was thinking we should go for it. This will also mean we can directly use assembly and create routines to directly access Archive (so we can keep sprites and tilemaps in archive, maybe even the App).

Sorunome · « **Reply #36 on:** December 08, 2012, 07:21:39 pm »

In my opinion we should go for app as it doesn't require a shell to run, and then, as you said, load stuff out of archive.

stevon8ter · « **Reply #37 on:** December 08, 2012, 07:41:48 pm »

Ok xeda idk but i think you're code isn't at it's max capabilty...?

And yeah i think it should be an app, with the axiom for routines and archived stuff

Sorunome · « **Reply #38 on:** December 08, 2012, 07:43:16 pm »

but aximos would kill the awesome feature that you don't need a other shell to run it

squidgetx · « **Reply #39 on:** December 08, 2012, 07:46:33 pm »

Axe already has some pretty good routines to work with archive, I don't think you'll need custom asm for that. Also axioms don't make you need another shell to run.

stevon8ter · « **Reply #40 on:** December 08, 2012, 07:48:20 pm »

Sorunome: if it's an app... You wouldn't need a shell...

Xeda112358 · « **Reply #41 on:** December 08, 2012, 07:48:42 pm »

Axioms don't make it so you need another app or program to run, it only means that you need them to compile the source.

Also, @stevon8ter: The program starts off with a Pause 100 at 6MHz. keep watching and I remove the Pause 100 and show its speed, then I show it at 15MHz. At 15MHz, WabbitEmu tells me I am getting 80 FPS and 60FPS at 6MHz. I think we should keep it at 6MHz for the main engine and routines so that it stays nicely compatible with the 83+

stevon8ter · « **Reply #42 on:** December 08, 2012, 07:50:09 pm »

Oooh ok, sorry but i'm on ipod so it could look a bit slower for me xD

Sorunome · « **Reply #43 on:** December 08, 2012, 07:52:11 pm »

Oh, i thought it also needs the axiom to running, three people confirmed now the other

so, why not use epic axioms?

stevon8ter · « **Reply #44 on:** December 08, 2012, 07:58:26 pm »

Because they contain fast routines so you don't have to write you own (most of the time slower) ones, for in example accessing archive etc

Author Topic: OmniRPG - Coding (Read 67111 times)

willrandship

Re: OmniRPG - Coding

Sorunome

Re: OmniRPG - Coding

Xeda112358

Re: OmniRPG - Coding

Sorunome

Re: OmniRPG - Coding

stevon8ter

Re: OmniRPG - Coding

Xeda112358

Re: OmniRPG - Coding

Sorunome

Re: OmniRPG - Coding

stevon8ter

Re: OmniRPG - Coding

Sorunome

Re: OmniRPG - Coding

squidgetx

Re: OmniRPG - Coding

stevon8ter

Re: OmniRPG - Coding

Xeda112358

Re: OmniRPG - Coding

stevon8ter

Re: OmniRPG - Coding

Sorunome

Re: OmniRPG - Coding

stevon8ter

Re: OmniRPG - Coding