Jump to content

Photo

M.U.L.E. for TI

PROGRAMMING ATARI MULE

120 replies to this topic

#51 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,910 posts
  • Location:Denmark

Posted Sat Jan 12, 2013 2:11 AM

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.

Posted Image

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

:thumbsup:

Edited by sometimes99er, Sat Jan 12, 2013 2:25 AM.


#52 Raccoon Lad OFFLINE  

Raccoon Lad

    Moonsweeper

  • 473 posts
  • I Like Pixels
  • Location:The Caverns of DEATH ...and Pineapples

Posted Sat Jan 12, 2013 7:12 PM

Oops, I guess I wasn't paying close enough attention when I did the chest. Here's a fixed version
Attached File  newchest.png   988bytes   21 downloads

#53 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,910 posts
  • Location:Denmark

Posted Sun Jan 13, 2013 12:19 AM

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 by sometimes99er, Sun Jan 13, 2013 12:42 AM.


#54 Raccoon Lad OFFLINE  

Raccoon Lad

    Moonsweeper

  • 473 posts
  • I Like Pixels
  • Location:The Caverns of DEATH ...and Pineapples

Posted Wed Jan 16, 2013 8:38 PM

Here's an alternate logo that could be used to do color effects similar to the atari version.
Attached File  logo2.png   685bytes   13 downloads

#55 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,910 posts
  • Location:Denmark

Posted Thu Jan 17, 2013 1:07 AM

Excellent Graphic Mode 1 technique ! :thumbsup:

May I suggest some minor changes ... :)

Posted Image

And also, how about a wider chest ... ;)

Posted Image

Edited by sometimes99er, Thu Jan 17, 2013 2:08 AM.


#56 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 656 posts
  • Location:in the San Antonio/Austin area? drop me a line, trying to get a retro computer club together.

Posted Thu Jan 17, 2013 10:25 AM

Here's an alternate logo that could be used to do color effects similar to the atari version.
Attached File  logo2.png   685bytes   13 downloads

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.

#57 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,141 posts

Posted Thu Jan 17, 2013 12:36 PM

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

#58 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 656 posts
  • Location:in the San Antonio/Austin area? drop me a line, trying to get a retro computer club together.

Posted Thu Jan 17, 2013 3:14 PM

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.

Attached Files



#59 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,141 posts

Posted Thu Jan 17, 2013 3:49 PM

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

#60 Raccoon Lad OFFLINE  

Raccoon Lad

    Moonsweeper

  • 473 posts
  • I Like Pixels
  • Location:The Caverns of DEATH ...and Pineapples

Posted Thu Jan 17, 2013 7:05 PM

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)
Attached File  titleanim.gif   9.43KB   46 downloadsAttached File  map-TI3.png   4.05KB   41 downloads

#61 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,692 posts

Posted Fri Jan 18, 2013 11:12 PM

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

#62 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,581 posts
  • Location:Flyover State

Posted Sat Jan 19, 2013 9:07 AM

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

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.

#63 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 656 posts
  • Location:in the San Antonio/Austin area? drop me a line, trying to get a retro computer club together.

Posted Fri Feb 1, 2013 11:25 AM

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

Edited by hloberg, Fri Feb 1, 2013 11:36 AM.


#64 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,581 posts
  • Location:Flyover State

Posted Fri Feb 1, 2013 11:38 AM

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

#65 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 656 posts
  • Location:in the San Antonio/Austin area? drop me a line, trying to get a retro computer club together.

Posted Fri Feb 1, 2013 11:57 AM

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.

#66 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • 1,692 posts

Posted Fri Feb 1, 2013 2:29 PM

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

#67 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,581 posts
  • Location:Flyover State

Posted Fri Feb 1, 2013 4:10 PM

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.

#68 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 656 posts
  • Location:in the San Antonio/Austin area? drop me a line, trying to get a retro computer club together.

Posted Fri Feb 1, 2013 4:43 PM

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.

#69 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,581 posts
  • Location:Flyover State

Posted Sat Feb 2, 2013 2:22 PM

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.

#70 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,317 posts
  • Location:Silver Run, Maryland

Posted Sat Feb 2, 2013 7:37 PM

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

#71 hloberg OFFLINE  

hloberg

    Dragonstomper

  • Topic Starter
  • 656 posts
  • Location:in the San Antonio/Austin area? drop me a line, trying to get a retro computer club together.

Posted Sat Feb 2, 2013 9:06 PM

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 by hloberg, Sat Feb 2, 2013 9:07 PM.


#72 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,317 posts
  • Location:Silver Run, Maryland

Posted Sat Feb 2, 2013 9:24 PM

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

#73 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,581 posts
  • Location:Flyover State

Posted Sun Feb 3, 2013 12:26 AM

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

#74 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,581 posts
  • Location:Flyover State

Posted Sun Feb 3, 2013 12:29 AM

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.

#75 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,317 posts
  • Location:Silver Run, Maryland

Posted Sun Feb 3, 2013 7:45 AM

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





Also tagged with one or more of these keywords: PROGRAMMING, ATARI, MULE

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users