I see a demo of Super Mario Bros floating around; could this have been done in 100% Turbo Forth?
If not, how does someone decide whether or not a port may or may not work under TF?
Jump to content
Posted Thu Jun 22, 2017 8:39 AM
If Turbo Forth is 5-6 times slower than assembly as the benchmark shows I would say no: you couldn't make the Super Mario Bros demo in TF. Unlike many of my demos and games that are spending most of their time in tight loops pushing data to the VDP, the SMB demo is depending on the F18A for scrolling and is using most of its time on game logic. So even adding some assembly routines to TF to do the heavy lifting wouldn't help much in this case. I'm sure lots of other arcade games are possible in TF with or without the F18A.
Edit: I should mention that I was running out of CPU power in the SMB demo, which is one of the reasons I stopped developing it.
Posted Thu Jun 22, 2017 10:51 AM
Turbo Forth has its own Assembler. Which is easier to use than the TI assembler. So real Forth programmers write in Forth then optimize the right loops with Forth Asm routines.
If you check the Tursi benchmarks postings you will see that I got the benchmark down to 6.5 seconds in Forth versus 5 seconds in the optimized Assembler version. And if I needed 5 seconds I would just write the outer loop in Forth Assembler too.
Remember when Tursi re-wrote the code using BLWP system calls the way you would start a project it took 17 seconds versus 48 seconds in in-optimized turbo Forth.
That is less than a 3 times difference in an apples to apples type comparison.
There are industrial examples at Forth Inc where they rewrote customers products that were in Assembler or C where the final Forth version was faster because they could test algorithms interactively and find better methods to solve the problem.
Algorithms normally beat language.
Edited by TheBF, Thu Jun 22, 2017 11:04 AM.
Posted Thu Jun 22, 2017 11:12 AM
FYI by "easier to use" I mean it is interactive in a way that is hard to imagine for Assembly language programmers.
You can write a simple code routine at the console like in BASIC and test it immediately.
Do this a few times and join them all together as a high level Forth routine and test that interactively.
It's pretty fun.
Posted Thu Jun 22, 2017 1:08 PM
That's one of the best things with Forth.
Posted Thu Jun 22, 2017 3:42 PM
Edited by Willsy, Thu Jun 22, 2017 3:46 PM.
Posted Thu Jun 22, 2017 3:48 PM
Posted Thu Jun 22, 2017 4:16 PM
Here's one I did 5 years ago. It was *seriously* easy to write. Done in an afternoon.
This is so cool! You did this in an afternoon and it was "easy" to write?
That's some skill you have cultivated my friend.
Posted Thu Jun 22, 2017 9:36 PM
Do you think TurboForth could handle something like this?
This is a TRS-80 CoCo game:
Posted Fri Jun 23, 2017 12:34 AM
Posted Fri Jun 23, 2017 8:52 AM
I forgot to ask - do you see anything in that game requiring a F18A?
Edited by courtesi96, Fri Jun 23, 2017 8:52 AM.
Posted Fri Jun 23, 2017 9:24 AM
I'm more than familiar with that game, my brother had it on his CoCo.
The original CoCo used the 256x192 high-res mode with 4 colors achieved through artifacting. So it translates fairly well to the TI with one exception; the graphics are not perfect squares. If you notice, the scrolling window is 12x15 in size. That means the graphics are actually 12 pixels high, 16 pixels wide. You would either just need a smaller window on the TI and do 16x16 size graphics, or you'd need to use bitmap mode and do some clever tricks to split things.
My own feeling is, don't try and force something into a graphics mode that doesn't fit well, I'd go with 16x16 size to keep the scale looking good.
Posted Fri Jun 23, 2017 8:58 PM
Posted Sat Jun 24, 2017 10:09 PM
I watched the whole video and I'm not seeing much that is particularly challenging. Things like scrolling the screen already exist in TF.
I'm seeing what looks like an 8x8 man, 8x16 ghosts/monsters, minimal animation (can be done by redefining colours or characters - very fast in TF).
The only programing "problem" you would have to solve (and this is nothing to do with Forth) is the map is very large, with quite a lot of rooms. So you'll need some sort of tokenisation system in order to represent each room as some sort of structure.
There's also the AI for moving the monsters intelligently. Again, not a problem that is specific to Forth. You'd have to solve it in any language. My approach in Forth would be to use DOES> and have a common set of routines for all monsters. Kind of like a class with multiple instances and common methods.
I think as a first project I'm going to try and convert this over to TF. First obviously I need to learn TF which I am currently doing. But also, I'm going to put this game through a disassembler to get the 6809 code and comment it up a bit to figure out how it crams all those screens into 32k. Probably too aggressive to finish this year but may be ready to show off in 2018.
Posted Fri Jun 30, 2017 8:16 AM
0 members, 0 guests, 0 anonymous users