Grotto Escape

[+Vorticon]

Very nice!

As far as time is concerned, you could try my method: I'm attempting to dedicate 1 hour a day for my TI programming projects... This usually tends to happen late in the evening, so an hour is probably all I can muster before having to retire so I can make it to work in the morning This also has the added advantage of keeping the program code fresh in your mind, which is a must for large projects. You see, once you reach the state where you have a truly global picture of program flow in your mind, your productivity really skyrockets because you don't have to keep relearning your code. Step away for a week or two and things start fading away, which makes it very difficult to come back. To give you an idea, I spent an entire weekend going over the code of Ultimate Planet after I had not touched it for several months before I could actually understand it enough to mess with it again. And even then, the new code I added has broken so many things that I've been slugging through bug after bug trying to get back to a functional state (nearly there!).

Good luck! I'm really looking forward to playing your game

[Willsy]

WOW!

 

Ho. Lee. Sheeyat. :lust: :lust:

 

I think I'm going to fall off my ch.....

 

 

 

 

...air.

 

Absolutely beautiful!

 

I've been looking for a showcase project for TurboForth. Can I have your permission to port the finished game to TurboForth? I'm quite confident that this game in TF will run perfectly fine on a stock TI - for example, you mentioned that you are continually redefining the same patterns for the animation in XB, which is slow but looks fine in Classic99 OD. Well, I can tell you, that in TF, you wouldn't have a problem, for 3 reasons:

 

You have access to all 256 ASCII characters for patterns

Sprites do not use the ASCII character set at all! They have 256 patterns all to themselves, which do not share the ASCII character set in any way

You can just redefine the same patterns over and over again if you want to. TF is fast enough to do that for you (but there probably wouldn't be any need - see reason 2 )

 

TF also has screen scrolling built in - you can scroll 32 column, 40 column, or 80 column screens (if you have the hardware).

 

To do screen scrolling in TF you use PANEL to define an (invisible) rectangle which will be scrolled by the SCROLL command. A variable exists called WRAP which will do a wrap around on your scroll area for you when set to TRUE.

 

So, with your permission, I'd like to take your game and port it. Is that ok?

 

Regards

 

Mark

[+Vorticon]

Is Turbo Forth now available for distribution?

[Willsy]

Not yet, but its very close. I wrote the last bit of code today (i hope). Final testing now...

 

Any additional stuff will come later as loadable libraries.

[sometimes99er]

Not yet, but its very close. I wrote the last bit of code today (i hope). Final testing now...

 

Any additional stuff will come later as loadable libraries.

What !? You're not making my TI Basic base shit a loadable pile of ... are you ? I thought we were talking core here !

[Willsy]

If I can find a find a way of adding it to the core, I will, believe me!

 

Hey, don't make me go up to 32k ROMs! If I go to 32K, you won't see TF for another year with all the stuff I'd pack into it!!!!!!

 

Top of my list would be the word: WRITE-MY-GAME-BITCH which just writes a game for you

Edited April 5, 2011 by Willsy

[Bones-69]

So, with your permission, I'd like to take your game and port it. Is that ok?

Mark, this would be fine, not only do I not have any objections to such a suggestion - I am excited that it might be possible.

 

Will get my head down and ass up and try and get it finished before the RDGC contest closes.

[Willsy]

Just bumping this thread - wondering if there's any progress?

 

Mark

[S1500]

Have any games been finished?

[Bones-69]

Quick update here as I have been missing in action lately.

 

Grotto Escape is still very much on the go. I have lately been spending a lot of time working out the best method to control and keep track of enemies.

 

My intention was once a screen has scrolled to a new location, enemies will "spawn" into existence. The trigger for controlling this information with so many maps is becoming a fine balance.

 

There are 26 enemy variables for each level which contain an enemy. My original intention was to load these variables either from disk or from program data upon initialization to keep the game play as smooth as possible (of the 26 variables only a couple will be required for the game save feature with the rest being fixed values). To load these during initialization I need something that resembles DIM (56,26) but this does put a huge drain on the little TI's memory. The alternative is to load 26 variables into a single one dimension array and read the new values each time the player scrolls to a new level. The preferred method is to fetch these values from disk so I am not needlessly chewing up Program Stack space but my testing shows this process will take around 4 seconds each time a new level is scrolled into play (even with CPU throttling).

 

At this moment I am leaning towards the pre-game initialization method (with values read from disk) but with the variables I have so far determined I need during the game this only leaves me around 2K to play with. If there is something I hadn't yet thought about this 2K with get chewed through real quickly. If I could get it down to a 4K buffer I am almost at the point now where I can start putting all the pieces together with confidence that the end product won't result in memory issues.

 

More homework needed.

[Willsy]

I'm glad to see this game hasn't died! I'd like to port it to TF when it's done!

 

A question: Your data. Is each datum an 8 bit item, or is there datum that could be > 255?

 

If 8 bit data, then you need 56*26=1456 bytes. If the data is smaller than 8 bits, it can be bit-packed and un-packed when you need to read it.

 

Rather than arrays (although I don't think they are particularly memory hungry) consider using strings to hold the data (one string per level, to get under the 254 character string limit?).

 

Finally, if you do need 1456 bytes, then an obvious place to store that would be in VDP, since there is probably loads of free space in VDP memory. I don't know how XB uses VDP, but it might be possible to store your data in VDP after the end of the sprite table or something like that. You'll need a bit of assembly to provide POKEV and PEEKV to put/get the data, but that should be easy enough to do.

 

Mark

[OX.]

Any progress on this game? This looks too awesome to go unfinished.

[Bones-69]

I really got on a roll with this one. Had a few levels almost created and was finalising some of the little programming challenges. It was almost writing itself. Then life got in the way and I haven't returned. I am sure I will return but will now have to almost start from scratch because my whole thought process now is gone. Not sure when time will allow me to throw some time at this project.

[Willsy]

Can you post what you have so far? I'd like to see if it's a good candidate to port to TurboForth.

 

If I wrote the game in Forth, would you be interested in designing the graphics?

[Bones-69]

What I have so far is more a collection of crap rather than a program. I have it all on an Excel spreadsheet - snippets of code, character defs, file & variable descriptions etc that nobody (including me for the most part), would make sense from. I have been going through it since the thread was bumped and I actually think time away has given me a fresh set of eyes on the whole idea. I have come up with some new ideas I don't remember having earlier. To be honest I think the little thread bump has re-excited me about this program.

 

My time management at the moment is just plain terrible so while I would be interested in playing any part in a "group project", and graphics would suit me probably quite well, I will just end up letting people down if I was to accept at this time.

[Bones-69]

For what it is worth... Attached is the document I was talking about. As I said, it's pretty unorganised and likely won't make much sense to anyone.

GA7.zip

Edited July 11, 2012 by Bones-69

[Willsy]

I read the spreadsheet; as you said, it probably makes more sense to you!

 

Where did the original screen shot that you did originate? Was it done in Magellan? If I were doing a Forth port I'd probably just take the graphics data, and write everything else from scratch.