New interpreted language?
Moderator: MaxCoderz Staff
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
New interpreted language?
I know pretty much all of us here have coded in basic at one point, but for MOST of us we learned the limitations of basic and have step up to ASM.
**cough** except kevin **cough**
Anyway, the big problem with asm is that it takes a long time to code simple tasks, you end up recoding things that you've done before with other projects. I don't know how many Mappers I've made in my time.
But when comes to programming a game you want a few things; Speed, graphics, ease of coding, and low memory cost. Basic provides none of these, and asm is missing the later two(some cases).
At some point we all thought what it would be like if we had a new interpreted language. NO more crashing, on calc programming, no more routine hunting(or creating) routines, in school programming when bored, and so much more.
I went as far as to actually make an interpreted language modeled after assembly expect it used floating point math and error checking. I actually had few graphic routines working, but the program sturcture needed work. I originally tried to rewrite all the math routines that I was going to use to be optimised to the precision I was using, but once I got to the division I kept on having wierd buggs. So it never took off.
I saw that RPL language, but it just seemed more complicated than necessary, looked fast though.
So with the recent article post at Ticalc, I'm wondering,
Is there a demand for a new language at all?
And if so what should it look like?
What should it be capable of?
What kind of logic should go behind the math, equation prasing, Reverse polar notation or something else?
I'm just curious, Is this a project I should pick back up , Someone else get started on or maybe even be a group effort.
**cough** except kevin **cough**
Anyway, the big problem with asm is that it takes a long time to code simple tasks, you end up recoding things that you've done before with other projects. I don't know how many Mappers I've made in my time.
But when comes to programming a game you want a few things; Speed, graphics, ease of coding, and low memory cost. Basic provides none of these, and asm is missing the later two(some cases).
At some point we all thought what it would be like if we had a new interpreted language. NO more crashing, on calc programming, no more routine hunting(or creating) routines, in school programming when bored, and so much more.
I went as far as to actually make an interpreted language modeled after assembly expect it used floating point math and error checking. I actually had few graphic routines working, but the program sturcture needed work. I originally tried to rewrite all the math routines that I was going to use to be optimised to the precision I was using, but once I got to the division I kept on having wierd buggs. So it never took off.
I saw that RPL language, but it just seemed more complicated than necessary, looked fast though.
So with the recent article post at Ticalc, I'm wondering,
Is there a demand for a new language at all?
And if so what should it look like?
What should it be capable of?
What kind of logic should go behind the math, equation prasing, Reverse polar notation or something else?
I'm just curious, Is this a project I should pick back up , Someone else get started on or maybe even be a group effort.
-
- New Member
- Posts: 60
- Joined: Tue 11 Jan, 2005 1:48 am
- Location: The Dark Tower, The Middle of Everywhere
umm: http://joepnet.com/hosted/maxcoderz/php ... c.php?t=71
also: http://65.254.50.194/~earthfor/dysfunct ... owforum=21
and: http://dysfunction.earthforge.com/?p=mlc.php
MLC86 is almost done , MLC83 status is unknown at the moment, gimpy and unknown are supposed to be working on it but i havent heard anything yet.
1: Speed - Check
2: Graphics - Check
3: Ease of coding - Check
4: Low memory cost - err... pending...
also: http://65.254.50.194/~earthfor/dysfunct ... owforum=21
and: http://dysfunction.earthforge.com/?p=mlc.php
MLC86 is almost done , MLC83 status is unknown at the moment, gimpy and unknown are supposed to be working on it but i havent heard anything yet.
1: Speed - Check
2: Graphics - Check
3: Ease of coding - Check
4: Low memory cost - err... pending...
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
I'd think it be hard with for coders considering the differences in hardware. Gray scales slower on the 83+, not to mention hard to sync up. And you dont have all that extra ram. Then the lcds are physical different in size. and a lack of an archive on the 86.
But mlc does look fast makes it seem possible for an 83+
I'd think it be better if the languages were were optimized for each calculator since the differences are pretty big.
But mlc does look fast makes it seem possible for an 83+
I'd think it be better if the languages were were optimized for each calculator since the differences are pretty big.
-
- Regular Member
- Posts: 110
- Joined: Wed 19 Jan, 2005 4:57 pm
- Location: Inside you
HELL YA
Its about time someone thought of it. I think a new language is defenitely a good idea
Phantom star contained over 6000 lines of code which i think is crazy for a simple shooter game
Phantom star contained over 6000 lines of code which i think is crazy for a simple shooter game
-
- Calc Master
- Posts: 1089
- Joined: Fri 17 Dec, 2004 9:53 am
hey
Well, status on MLC 83: still waiting for burntfuse's new pre-port.
Havent spoken to him in a while, and he's not on the forum much either :S
I think MLC 83(+/se/84+/se) is possible... But it would be hard work, for optimizing and such. I hope we can do it :p
Havent spoken to him in a while, and he's not on the forum much either :S
I think MLC 83(+/se/84+/se) is possible... But it would be hard work, for optimizing and such. I hope we can do it :p
-
- New Member
- Posts: 60
- Joined: Tue 11 Jan, 2005 1:48 am
- Location: The Dark Tower, The Middle of Everywhere
the 83 poses some unique problems, and if we determine that it would be pointless to have MLC for the 83 because of its limitations then it might be time to make an 83 specific language so that you guys dont get left out. but before that happens we'll strip down MLC to its bare essentials to see if it will work (remove grayscale, etc) while still remaining compatible with the other MLC versions. Im not an 83 expert so i really cant say for sure what will happen, but judging from MLC86 I have high hopes
-
- Regular Member
- Posts: 86
- Joined: Fri 17 Dec, 2004 8:20 pm
- Contact:
Why not just make a new mirageOS compatible shell, but include as many useful routines as possible. things like
- A "generic" tile mapper (smooth scrolling 8*8 tiles)
- Rotationg/mirroring sprites (to save memory)
- Stretching/shrinking sprites (It seems to me that Dwedit made a program a while ago that would zoom 2x and smooth the edges)
- Common math routines like multiplication,division,square root,powering,ect. (or is this already in mirage?)
- A sine table
- Optimized vertical/horizontal lines
- Compression (like CrunchyOS, but to a larger extent)
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
Thats actually a really good idea, it'd be perfect for those massive rpg games. And since the game would be aligned to a page, it'd be great for reading directly from the archive. and that would leave the ram free for MLC(or something else).On the 83+ there's always flash app whichcould be an option for large game. The user could have the choice of making the game as an app or a prgm.
But theres one problem, you can't make app on the calculator, TI-OS doesn't like that. It would have to come from the computer, but for the more complex games it's still a good solution, and might make it easy to port games from the 86 to the 83+.
@stickman
those would be nice but doesn't hanlde the LESS crashing or on calc coding.
One thing that slows noobs from learning how to programming is that for most of them it's hard to compile the damm program, tasm really isn't that friendly.
Then it's spits out 3000 lines errors when they are only trying to make "hello world".
ANd finally when they get past that, It clears their ram, and not before saying "good bye cruel world".
We should aim for a coder friendly language.