M.U.L.E. for TI

[sometimes99er]

I never had a TI-99/4a, but I have a fondness for the TMS-9918a. Making TI/Coleco/Sg-1000/MSX graphics is fun and challenging, and every so often I get the bug to make art with the 16 colors 2 colors per line / character limitations. I poke me head in here every so often because I love to see people making games. That's probably the main reason I hang around AA is for the homebrew scene.

 

For a split second I forgot about the other platforms. Don’t know what happened.

 

Some of the programming languages mentioned in this thread do not directly support bitmap modes, so the art might have to stick with the 2 colors per character. Looks like you're already there and then spicing up the Wampus with a few support sprites. Cool.

 

Anyway, for graphics, I use ProMotion. It's kind of expensive for the average user, but I got a copy for free some years back while doing professional game art. When I do tms9918a graphics, I usually just turn on the 8x8 pixel grid, zoom in and try to remember to keep the colors to 2 per character.

 

I use PaintShopPro, AnimationShop, Flash and Photoshop. ProMotion looks very impressive, and as they say, based on Amiga Deluxe Paint. Nice.

 

Magellan, Grapefruit, CartographPC and Patterns are pretty limiting to an artist when comparing to the other products mentioned, they can however produce data for different programming languages. Since you’re not going to program (I guess), you can easily stick with ProMotion.

 

There’s also Tile Extractor. Takes a screen image (like the ones you made) and automatically breaks it into screen data and unique characters. You have to rearrange things for the Graphics 1 mode though (due to the 2 colors per 8 character limitation). Think I have a 9918 Graphics 1 version on my list – if not, I’ll put it on.

 

 

Love how you “get around” the character limitation with the treasure chest.

 

Edited January 12, 2013 by sometimes99er

[Hakogame 箱亀]

Oops, I guess I wasn't paying close enough attention when I did the chest. Here's a fixed version

[sometimes99er]

Oh, I didn't even see that one. Wasn't trying to imply anything. Maybe a 3 character wide chest would look more "natural" - as it almost looks deeper than wide right now ?

Edited January 13, 2013 by sometimes99er

[Hakogame 箱亀]

Here's an alternate logo that could be used to do color effects similar to the atari version.

[sometimes99er]

Excellent Graphic Mode 1 technique !

 

May I suggest some minor changes ...

 

 

And also, how about a wider chest ...

 

Edited January 17, 2013 by sometimes99er

[+hloberg]

Here's an alternate logo that could be used to do color effects similar to the atari version.

Excellent, excellent work. have downloaded all the pictures. I'm still not sure if I plan to go with the new NES look or the cruder original Atari 800 (&C 64) look. Since I'm still a long way from that point of the art work I'll put off for that decision for later. I might do a mix of both for an original look, I don't know.

[+adamantyr]

Graphics are cool, but the game engine is the most important part to figure out.

 

So far, I haven't found any site breaking down the EXACT nature of the algorithms that drive the game. Reading source code would be a rather painful way to figure them out too.

 

Adamantyr

[+hloberg]

Graphics are cool, but the game engine is the most important part to figure out.

 

So far, I haven't found any site breaking down the EXACT nature of the algorithms that drive the game. Reading source code would be a rather painful way to figure them out too.

 

Adamantyr

check out the html and disassemble files in this .zip file (you may have already seen this) Unfortunately it's a mix of French and English but this guy explains a lot of code. When I get this far I think I can figure out most of it from the notes.

MULE disassem.zip

[+adamantyr]

check out the html and disassemble files in this .zip file (you may have already seen this) Unfortunately it's a mix of French and English but this guy explains a lot of code. When I get this far I think I can figure out most of it from the notes.

 

Ah, I see it. Yeah, this is the same kind of stuff I had with Eastern Front...

 

The pseudo-code on the side is probably the most valuable... if he gives any extended comment explanations for blocks of code as to how it works beyond even IF/THEN logic, then it's definitely gold.

 

Adamantyr

[Hakogame 箱亀]

May I suggest some minor changes ...

 

Hmm, that's exactly what I was trying to do with the M in the first place. I think I was trying too hard to have the outlines on separate characters from the inner color, and completely missed doing that initially.

 

Anyway, here's an animated title screen and an alternate version of the map screen (thicker borders)

[+InsaneMultitasker]

ok guys. Seriously. I read this topic before work today, and I had the M.U.L.E. theme song stuck in my head ALL day. Is the game done yet? hehehe

[JamesD]

ok guys. Seriously. I read this topic before work today, and I had the M.U.L.E. theme song stuck in my head ALL day. Is the game done yet? hehehe

Dum da da daaaa... de de de dum da da daaaaa!!!!!!!!!

Yeah, I've had it going through my head a lot since this thread started.

[+hloberg]

After checking various programming languages I think I have figured out how I'm going to create MULE.

I think I'm going to create it in XB with some assembler extensions.

My reasoning Is I think I can get a very, very close look to the Atari 8bit version (with some fancy graphics thrown) with XB, show the power of XB and have a quick programming cycle.

As of now, the two assembler extensions I will need are:

MOVE byte from RAM to VDP routine, which is in various XBs (my favorite is XB 2.5) This will enable me to pop in the various screens quickly by saving the chars. to memory then moving them back to VDP.

The ability to PLAY music in the background while various things happen on the screen (which I have seen somewhere as an extension to XB).

Another good assembler routing I might use is load LOAD TI-Artist screens. The Title screen may be just that, a drawing with auto music and a sprites.

I'm looking to see where I have said routines to add and I'll put them in. That is, unless someone already has them at hand and would like to donate them to the cause so I don't have to look through 16gb of extremely unorganized TI data on my hard drive. .

Edited February 1, 2013 by hloberg

[JamesD]

XB... so much for my dream of a more portable version.

[+hloberg]

XB... so much for my dream of a more portable version.

Don't worry. If I get this working well I'm going to redo it in 'C' or Forth. There is just so much one can do with XB.

But having to learn TI 'C' or Forth, then debug it, then program it would take way too long. Now I can learn Forth (or TI's version of C) while still working on MULE's logic which I can translate later.

[+InsaneMultitasker]

Don't worry. If I get this working well I'm going to redo it in 'C' or Forth. There is just so much one can do with XB.

But having to learn TI 'C' or Forth, then debug it, then program it would take way too long. Now I can learn Forth (or TI's version of C) while still working on MULE's logic which I can translate later.

I perodically do something similar - I will work out complexities in XBasic and then convert to assembly.

[JamesD]

I have no problems with working out some logic in BASIC first but almost all user interaction in MULE requires real time response.

Not exactly something Basic is good at.

 

Forth just isn't intuitive enough IMHO.

If I ask you to show me all the major modern applications written in Forth it won't take long... they just don't exist.

GCC was originally designed for use from Unix so it isn't exactly a beginner's tool, it's not terribly difficult but there is a learning curve just moving to a compiler.

The problem with either language is that you'll be creating a lot of stuff from scratch.

If you have a look at the code for the programs that have already been written for GCC they may offer some insight.

[+hloberg]

I have no problems with working out some logic in BASIC first but almost all user interaction in MULE requires real time response.

Not exactly something Basic is good at.

 

Forth just isn't intuitive enough IMHO.

If I ask you to show me all the major modern applications written in Forth it won't take long... they just don't exist.

GCC was originally designed for use from Unix so it isn't exactly a beginner's tool, it's not terribly difficult but there is a learning curve just moving to a compiler.

The problem with either language is that you'll be creating a lot of stuff from scratch.

If you have a look at the code for the programs that have already been written for GCC they may offer some insight.

 

That's one of the reason's I'm working out the logic in XB before I jump to another language. Not sure where I'm going next.

Forth is a bit complex. It's like java so not too foreign to me but it would take a bit to learn.

GCC, maybe. I'm not a big fan of cross compilers, I feel like I'm cheating but if it works, it works.

I have started some stuff in C99 with Funnelweb. Funnelweb takes a lot of the pain out of compiling C99 and I know C plus there is a large library with C99 to tap and some tutorials.

Still, now I'm creating some XB graphics from the stuff 'Raccoon Lad' posted; then logic. Both can all be done in XB.

One thing I noticed about MULE, even though it is real time the events are divided nicely into chunks that XB should be able to handle.

Ex: bidding on land plots. cursor moves to plot, check if joyst pushed, did others bid and did they have higher priority? give to winner. did computer player miss out? y/n yes-check for next it might want from pre list of choices. move to next plot.

[JamesD]

Forth is a bit complex. It's like java so not too foreign to me but it would take a bit to learn.

Java is much closer to C++ than Forth. I think the closest thing I've seen to Forth is F# and I find that's even more intuitive than Forth.

[+Lee Stewart]

Java is much closer to C++ than Forth. I think the closest thing I've seen to Forth is F# and I find that's even more intuitive than Forth.

 

OK...I gotta jump in here. Forth is very intuitive and very compact. It's why a lot of systems in appliances, automobiles, etc. are Forth based. The difficult part is getting into a Forth mode of thinking when most programmers' experience is otherwise. The biggest difficulty for me was postfix notation, a.k.a. reverse polish notation, versus infix notation that almost every other computer language employs. Forth does not require the programmer to write a test harness while working on a program. Each word (function) is executable as soon as it is composed, which is great for testing. Forth encourages functions with very small footprints. You can write intuitive, structured Forth assembly code that translates one-to-one into the same machine code you would get if you had written it in decidedly non-intuitive assembler. You can even use high-level Forth words in that structured assembly code. Sorry, I'm rambling. I'll stop for now...

 

...lee

[+hloberg]

the thing I found that Forth is like java is both you build words that drives it. The RPN is what makes forth the bugaboo but I'm from the old school (ever hear of the RPN HP calculators?) so I was exposed to RPN way back.

Still leaning to C after the XB test build of MULE though, just cause I know it.

FYI: working on the graphics and they are looking good. Getting the limited XB graphics looking like 'raccoon lads' with only minor variations.

Edited February 3, 2013 by hloberg

[+Lee Stewart]

...ever hear of the RPN HP calculators?...

 

Yeah, I was 29 when the HP-35 was introduced. I got to use one occasionally (too expensive for my grad-student budget, unfortunately).

 

...lee

[JamesD]

OK...I gotta jump in here. Forth is very intuitive and very compact. It's why a lot of systems in appliances, automobiles, etc. are Forth based.

If Forth is so popular then why are there are zero Forth jobs listed on Dice or Monster? I know, I checked.

 

Forth does not require the programmer to write a test harness while working on a program. Each word (function) is executable as soon as it is composed, which is great for testing.

This is one of the reasons why I said F# and Forth were similar.

And the intuitive nature of that language will doom it to a niche market.

 

Forth encourages functions with very small footprints. You can write intuitive, structured Forth assembly code that translates one-to-one into the same machine code you would get if you had written it in decidedly non-intuitive assembler. You can even use high-level Forth words in that structured assembly code. Sorry, I'm rambling. I'll stop for now...

 

...lee

"I have yet to see a decent piece of software written in Forth. Let's face it. Forth stinks." --- John Dvorak, provocateur and columnist, InfoWorld, October 29, 1984.

 

Just sayin...

[JamesD]

the thing I found that Forth is like java is both you build words that drives it.

words? You mean classes?

 

The RPN is what makes forth the bugaboo but I'm from the old school (ever hear of the RPN HP calculators?) so I was exposed to RPN way back.

Still leaning to C after the XB test build of MULE though, just cause I know it.

FYI: working on the graphics and they are looking good. Getting the limited XB graphics looking like 'raccoon lads' with only minor variations.

I'd be happy to help translate to C. I could build an Adam version based on the same code/graphics.

[+Lee Stewart]

words? You mean classes?

Forth words are not classes. It is the term for the executable definitions stored in the dictionary (a linked-list) of the extensible, threaded Forth language.

 

...lee