Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411275 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 05:16:12 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)TiBasic -> java/c
Pages: [1] 2
Print
Author Topic: TiBasic -> java/c  (Read 9301 times)
dustin
Level 6
*


View Profile
« on: April 07, 2008, 01:31:00 PM »

Ok so BaronCid had that idea for a tibasic compiler for x86.  I don't really have much compiler experience and don't really feel like writing x86 assembler so yeah.  Instead we talked about it and making a tibasic->c converter seemed easier and also more useful.  It could easily call gcc or whatever if it wanted to act like a compiler.

Anyway I'm writing it now.  Here's how it's going down...

I'm writing it in java at the moment because it's string minipulation is nice

as of right now it turns tibasic into java code but so far it's only stuff that is similar in all c like languages.  It's just java so I don't have to switch environments to test it out.  I'll switch this to c when I get to graphics probably

I'll probably be doing the graphics with SDL unless anyone can think of something better

Right now I have pretty much most of it running in text mode but obviously there are a lot of details I have to iron out

This thread is, in addition to getting feedback, so I can keep track of my progress in a well documented way.

Things go do
copied form baron cid...

Basic ones:
- +,-,*,/,log(),sin(),cos(),tan(), root(), ^, (, )  (mathematical)
- # (defines a Variable/String/List-Value/Matrix-Value)
- [ and ] (open and close blocks)
- If()  (Starts an if-bracket)
- Stop (Stops and closes the programme)
- Return() (Stops a subprogramme and returns to the place the subprogramme was
          executed at)
- Pause (Stops the programme-flow until the user presses the Enter-key)                             
- wait()     (stops the programme-flow for a certain amount of time) (in ms)
- starttimer() (starts a timer and stores the value in a certain variable)(in ms)
- stoptimer() (stops the timer of a certain variable)
- lbl()     (sets a point int the code. the programme returns to lables through
             goto()-commands.)
- goto()    (searches for a lable and returns to it)
- Repeat()  (repeats the commands in the block until the statement in brackets
             is true)
- While()  (repeats the commands in the block until the statement in brackets
- exec()   (executes a Subprogramme)
-rand(,)   (corresponds with a random value between the two given in the
            brackets)

Logic and test:
- =, >, <, <=, >=   (used in statements for if-, repeat- and while-functions)
- and, or, xor      (used in statements for if-, repeat- and while-functions)

Input/Output/Graphics/Sound:

- Output( , , )  (displays a string, variable or a line of charakters on
                  a certain position of the screen)

- Input()     (pauses the programme-flow. The player has to input
                    a string/number and press the enter-key to continue)
- ClrHome       (all pixels on the screen are turning white)

- BlackHome     (all pixels on the screen are turning black)
- checkkey()    (checks if a key is being pressed at the moment and stores
                 a 0 or a 1 in a certain variable (pressed=1, not pressed=0))
- pxlon( , )       (turns the pixel of a certain coordinate (x,y) black)
- pxloff( , )       (turns the pixel of a certain coodinate (x,y) white)
- pxlchange( , )   (changes the color of a pixel of a certain coordinate)
- pxltest ( , , )  (checks a pixel of a certain coordinate and saves it's state
                    (on/off -> 1/0) to a certain variable)
- startsound()     (starts playing a .tis-file from the sound-folder)
- stopsound()      (stops playing a .tis-file from the sound-folder)

Data-management:
There are 4 data-types:
- VAR (variables)
- STR (strings)

- LST (list, a 1-dimensional array)
- MTX (matrix, a 2-dimensional array)

Sound:
No exact ideas yet...

« Last Edit: April 07, 2008, 01:39:55 PM by dustin » Logged
jcromartie
Level 0
***


View Profile
« Reply #1 on: April 07, 2008, 04:41:41 PM »

Can I just point out that FreeBASIC is an existing BASIC->x86 native compiler.  You could consider using it instead of TiBasic, or just check it out for some examples of how it works.  Good luck.
Logged
dustin
Level 6
*


View Profile
« Reply #2 on: April 07, 2008, 05:02:16 PM »

whoops sorry for posting in the wrong forum.  And to jcromartie yeah I'm not really to familiar with any forms of basic. 

And as for freeBasic I don't really have any experience at all with any of the basic type languages so yeah.  It sounded like Baron Cid had some good reasons why he wanted a tibasic compiler and it sounded like fun so yep.  Maybe he can tell you the differences more fully.  I don't really even have any intention of writing games in tiBasic but hopefully at least a tech demo will be written or something...  This is more just something to test my programming skills.  I enjoy programming things other then games and I need something to code when I'm not feeling creative and this seems like it fit the bill and could even lead to some interesting games Smiley
Logged
Guert
Level 10
*****



View Profile WWW
« Reply #3 on: April 07, 2008, 05:20:23 PM »

whoops sorry for posting in the wrong forum.  And to jcromartie yeah I'm not really to familiar with any forms of basic. 

No worries Smiley
Logged

jcromartie
Level 0
***


View Profile
« Reply #4 on: April 07, 2008, 07:01:54 PM »

I think that the general gist of BaronCid's TI-BASIC rant was that a limited environment would be fun.

His main points were:

* 96x64 pixels (low-res)
* monochrome
* either no sound or low-fi sound

I think this is achievable without an obscure dialect of BASIC that gets compiled to C or anything like that.

Honestly this sounds like a fun idea, and I would love to build something like it.
Logged
dustin
Level 6
*


View Profile
« Reply #5 on: April 07, 2008, 08:50:54 PM »

Quote
I think this is achievable without an obscure dialect of BASIC that gets compiled to C or anything like that.

Honestly this sounds like a fun idea, and I would love to build something like it.

Well I don't think it's that obscure a dialect and I assume it has to be an ok language as it drives people to type on their calculators Smiley

But yes I agree that I wouldn't want to be writing anything in any type of Basic.  That said I'll have to write all the SDL stuff in C anyway so it would be no problem to just release all that stuff and people would have a super easy way to get a window open and display super simple graphics using C.
Logged
dustin
Level 6
*


View Profile
« Reply #6 on: April 07, 2008, 10:54:25 PM »

OK I'm pretty sure I'm done with all the actual transforming of code.  That's not to say everything works yet.  Right now all the stuff that isn't crossed of just makes calls to functions that don't do anything yet but luckily most of these will be super easy to write... example

double sin(double theta){
return Math.sin(theta)
}

is all that the sin one is...

So now I'm probably going to..

switch it over to C
write the rest of the functions
pull in the SDL
get graphics working
add in some extra stuff to display shapes (this seems like it would be usefull?)
particle engine Smiley ?
Logged
Lukas
Level 3
***



View Profile
« Reply #7 on: April 08, 2008, 04:48:12 AM »

Quote
I think that the general gist of BaronCid's TI-BASIC rant was that a limited environment would be fun.

Are "presentation of an idea", "expressing a vision" and "sharing a thought" the new meanings for rant, nowadays?  :D

Quote
add in some extra stuff to display shapes (this seems like it would be usefull?)
particle engine  ?
I don't think we actually need such things so far. They aren't a must. Smiley
And I don't know how much fun a particle engine would be with 96x64-monochrome-pixels. Wink Tongue


BaronCid

Logged

I make (60s/70s) rock music. Listen to my band's new album here: www.speicher.bandcamp.com
dustin
Level 6
*


View Profile
« Reply #8 on: April 08, 2008, 11:21:54 AM »

Quote
Quote
add in some extra stuff to display shapes (this seems like it would be usefull?)
particle engine  ?
I don't think we actually need such things so far. They aren't a must. Smiley
And I don't know how much fun a particle engine would be with 96x64-monochrome-pixels. Wink Tongue

yeah well I know I'll want them for a tech demo type thing I plan on writing when it's done so yeah... I think a particle engine could be pretty fun Smiley Some nice monochrome explosions/blood Wink
Logged
dustin
Level 6
*


View Profile
« Reply #9 on: April 10, 2008, 08:55:14 PM »

ok so I have graphics going now I am having one problem that I thought maybe people here might have some insight on.

TiBasic has pixelOn and pixelOff functions turning the pixels on and off

I'm updating the display at a flat rate of 60 fps I don't really see any reason for higher then that and you'd have to have a really lame computer to need it to run lower then that. Smiley  This simplifies things a lot for the end user as they can animate things easier.  I know there are disadvantages to the flat rate but simplicity is more important for this project.

The problem I'm having is this.  The users gona have some code running lets say it's for a moving pixel that moves to the right once a frame.  In order for them to know when to increment x there will have to be some waitForFrameDraw command.  does anyone understand what I'm saying.  It feels very hard to articulate.  I know in DS programming we had it and it was called WaitForVBL();  which  just waited for the frame to be drawn so you could change memory again.

If anyone knows a way around this or a better way to explain it please post
Logged
bigbossSNK
Level 1
*


View Profile
« Reply #10 on: April 11, 2008, 12:29:24 AM »

I suspect, though with no degree of authority, that you are referring to Vsync.
Here's a link
I don't know when it was last vaccinated, so if it bytes you, seek medical assistance.
Logged
jcromartie
Level 0
***


View Profile
« Reply #11 on: April 11, 2008, 05:59:08 AM »

I'm updating the display at a flat rate of 60 fps I don't really see any reason for higher then that and you'd have to have a really lame computer to need it to run lower then that. Smiley

What are you using for graphics?  Is this going to be cross-platform?

The problem I'm having is this.  The users gona have some code running lets say it's for a moving pixel that moves to the right once a frame.  In order for them to know when to increment x there will have to be some waitForFrameDraw command.

Why not just have the user define an "update" function and a "draw" function, and then let the back-end code call those user-defined functions.  That is how I've always approached it.  That way you can handle timing and vsync and all that jazz outside of the user's code.
Logged
dustin
Level 6
*


View Profile
« Reply #12 on: April 11, 2008, 08:26:18 AM »

Quote
I suspect, though with no degree of authority, that you are referring to Vsync.
Here's a link
I don't know when it was last vaccinated, so if it bytes you, seek medical assistance.

yep that is what I'm talking about.  But I know how to do it, just not how to do it without letting the end user know Smiley

Quote
Quote from: dustin on April 10, 2008, 08:55:14 pm
I'm updating the display at a flat rate of 60 fps I don't really see any reason for higher then that and you'd have to have a really lame computer to need it to run lower then that. Smiley

What are you using for graphics?  Is this going to be cross-platform?
yeah I'm using opengl at the moment it's all very cross-platform, I'm working from a mac so if I made it only one platform not many people could use it Smiley

Quote
Why not just have the user define an "update" function and a "draw" function, and then let the back-end code call those user-defined functions.  That is how I've always approached it.  That way you can handle timing and vsync and all that jazz outside of the user's code.

I was thinking of this too but I thought it might be more confusing instead of less.  It would be very easy to program in and I can see how it would make things convenient.  I'll ask around and see what people think.
Logged
Lukas
Level 3
***



View Profile
« Reply #13 on: April 11, 2008, 10:47:38 AM »

Quote
"update" function

I don't think we should implement such a thing.
This going to be a programming language. Not a game-programming-language.
Of course there are 60fps but taking the frame-management out of the programmer's hand completely is not the right thing to do, imo.

There should be just 2-3 basic graphical commands:
"White-pixel-on", "Black-pixel-on" and maybe "Grey-pixel-on".
I know enough people who wouldn't like to apply to some strange refreshing logic... including me.

+refreshing may be useful if you have a graphical "engine" running but for the programmes that are going to be created on that basis there isn't need for much more than "pixel-on" and "make-the-whole-screen-black/white/grey".
If the programmer doesn't choose to set up an array which handles all the pixel-information so that the display has to update it's output for every frame... that should be okay. Maybe you need such a thing to programme a more complex game but that's what subprogrammes are for: If you write a subprogramme which makes the entire screen "white" and draws the right pixels using array-data immediately afterwards you can include the execution of that subprogramme into your code everytime you need such a thing. Smiley


BaronCid
Logged

I make (60s/70s) rock music. Listen to my band's new album here: www.speicher.bandcamp.com
jcromartie
Level 0
***


View Profile
« Reply #14 on: April 11, 2008, 11:38:22 AM »

Quote
"update" function
This going to be a programming language. Not a game-programming-language.

I know it's your brain-child, but ...

I mean, go ahead and make a general purpose programming language if you want to... but everything you've described so far sounds like a simple game programming API.  Why not just set up SDL at 96x64 with a few grayscale colors, and make a few convenience functions?  If you want to make it more dynamic and easier to program then throw in a scripting language.

I'm just wondering if I can talk you out of *actually* writing some sort of compiler.  I mean, in the other thread BaronCid said that his "main point" was that "Ti-Basic is a really neat little programming language."  I am obligated to refute that point because it's just not true.

Have you seen languages like Lua, Python, or Ruby?  I mean, let's just compare Ti-Basic to Lua.

Code:
:1 # VARx

vs.

Code:
x = 1

and

Code:
:Repeat(VARx=4)
:[
:VARx+1 # VARx
:]

vs.

Code:
repeat x = x + 1 until x == 4

You might say it's a matter of taste... but I think there are a few measurable advantages in Lua's favor.  One: readability.  Just try reading the examples.  They read, in order, like this:

"Take 1, put it in a VAR called x."

vs.

"x is 1."

and ...

"Repeat, until the VAR called x is 4, the code inside the lines with square brackets, which takes the VAR called x and adds one to it, and puts it (back) into a VAR called x."

vs.

"repeat the operation (x is x plus 1) until x equals 4"

I also don't see any capacity to define functions, which really hampers anybody with any mathematical or programming inclinations.
« Last Edit: April 11, 2008, 01:30:10 PM by jcromartie » Logged
dustin
Level 6
*


View Profile
« Reply #15 on: April 15, 2008, 11:00:36 AM »

Quote
I don't think we should implement such a thing.
This going to be a programming language. Not a game-programming-language.
Of course there are 60fps but taking the frame-management out of the programmer's hand completely is not the right thing to do, imo.

ok it's easy for me to not put something in Smiley .  That said I know I'll be using one for myself.


Quote
If you want to make it more dynamic and easier to program then throw in a scripting language.

I'm just wondering if I can talk you out of *actually* writing some sort of compiler.  I mean, in the other thread BaronCid said that his "main point" was that "Ti-Basic is a really neat little programming language."  I am obligated to refute that point because it's just not true.

Have you seen languages like Lua, Python, or Ruby?  I mean, let's just compare Ti-Basic to Lua.

yeah I do not think tiBasic is a very easy programming language I much prefer python, java, or c even.  They just make more sense to me.  That said most of the work here is going to be me setting up a simple to use graphics framework.  I've been writing out some pseudo code for games (what I want to be able to actually write pretty much) and I can see getting games going in very few lines of code.

Of course there is no way I'll be programming anything in tiBasic I will just use the original language of whatever I code it in (right now java).  The tiBasic interpreter is really pretty simple to write and it sounded like a fun little project so I figured I'd throw that in too.  I don't really see how it's a very simple language but I don't really feel like I'm in a place to comment about that.  I'm a computer Science student so not really the type of person who is qualified to tell whether or not the average person thinks the language is easy.
Logged
jcromartie
Level 0
***


View Profile
« Reply #16 on: April 15, 2008, 12:05:07 PM »

Care to share some of the pseudocode?  I want you to know that I'm not trying to shoot down the limited/lo-res/lo-fi game development idea.  Not at all!  I actually love that idea; it's the Ti-Basic that I absolutely can't allow.

I have a moral obligation to save people from the tragedy that is a terrible programming language Cry

I've been working on my own take on this idea.  It probably won't go too far or really become a game, but it has been fun to tinker with paletted graphics and scripting.



Here is the Lua source code for that little shooter (just a ship, scrolling stars, bullets, pause screen).

Some of my favorite features are things like this:

Code:
  for i = 1, 100 * star_screens do
    local coord = {math.random(0, stars.w), math.random(0, stars.h)}
    stars[coord] = math.random(dgray, lgray)
  end

and ...

Code:
  play_keys = {
    down = {
      [keys.up] = moveup,
      [keys.down] = movedown,
      [keys.z] = fire,
      [keys.s] = screenshot,
      [keys.p] = pause,
    },
    up = {
      [keys.down] = stopmoving,
      [keys.up] = stopmoving,
    }
  }

It's all very WIP and just a bunch of ideas.  I don't have any sort of firm idea for a game to make with it.  I like the colors and the code... that's all.
Logged
dustin
Level 6
*


View Profile
« Reply #17 on: April 15, 2008, 12:36:19 PM »

Quote
I want you to know that I'm not trying to shoot down the limited/lo-res/lo-fi game development idea.  Not at all!  I actually love that idea; it's the Ti-Basic that I absolutely can't allow.

I have a moral obligation to save people from the tragedy that is a terrible programming language Cry

baronCid is the one who'll need convincing about that as I won't be using the ti-basic to write my lofi games with.  I'll end up just skipping that step and using the straight java that I'll write the engine with.

my pseudo code for a very simple racing game looks like this...

if(keys['w'])playerx++;
if(keys['a'])playerx--;
scroll(playerspeed);
drawline(roadx,0,roadx+roadw,0); //this needs to be repeated for however much I scroll
drawsquare(playerx,playery,2,2);
if(collision) reset();
if(rand()>0.9) roadvelx=1,0,or-1;
roadx+=roadvelx;

And that seems like everything.  The keys move the player (the keys array will get updated every frame by my background code/engine sort of thing).  Scroll will just move all the pixels on the screen down by playerspeed amount (I guess I'll have to give it a direction too in real life). drawline just draws a line. draw square will draw a square on the screen by switching the pixels from on to off.  When anything gets drawn if it hits any pixels that arn't it's color it will set the collision boolean to true.  If it doesn't hit any pixels it will set collision boolean to false.  That's why after I draw the square I check collision to see if it hit anything.  If it does I call reset() which will just end the thread and then call it again effectivly quickly starting and then stopping the program. roadvelx just handles turns and stuff.  Note I haven't thought about this too much i just whipped it up in class but I don't see any reason it shouldn't work.  I did a couple of other games like this and it seemed to work well.
« Last Edit: April 15, 2008, 12:38:04 PM by dustin » Logged
bigbossSNK
Level 1
*


View Profile
« Reply #18 on: April 15, 2008, 12:37:10 PM »

Martie, that code is awesome. If all lua is like that, I'd learn it just for the kicks.
Logged
jcromartie
Level 0
***


View Profile
« Reply #19 on: April 15, 2008, 01:15:19 PM »

my pseudo code for a very simple racing game looks like this...

if(keys['w'])playerx++;
if(keys['a'])playerx--;
scroll(playerspeed);
drawline(roadx,0,roadx+roadw,0); //this needs to be repeated for however much I scroll
drawsquare(playerx,playery,2,2);
if(collision) reset();
if(rand()>0.9) roadvelx=1,0,or-1;
roadx+=roadvelx;


That's pretty terse.  I guess it's a trade-off between flexibility and simplicity of the API.  Good food for thought.  It's dead simple, that's for sure!
Logged
Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic