dustin
Level 6
|
|
« 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
|
|
« 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
|
|
« 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
|
|
|
Logged
|
|
|
|
Guert
|
|
« 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
|
|
|
Logged
|
|
|
|
jcromartie
|
|
« 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
|
|
« Reply #5 on: April 07, 2008, 08:50:54 PM » |
|
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 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
|
|
« 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 ?
|
|
|
Logged
|
|
|
|
Lukas
|
|
« Reply #7 on: April 08, 2008, 04:48:12 AM » |
|
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 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. And I don't know how much fun a particle engine would be with 96x64-monochrome-pixels. BaronCid
|
|
|
Logged
|
|
|
|
dustin
Level 6
|
|
« Reply #8 on: April 08, 2008, 11:21:54 AM » |
|
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 Some nice monochrome explosions/blood
|
|
|
Logged
|
|
|
|
dustin
Level 6
|
|
« 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. 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
|
|
« 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 linkI don't know when it was last vaccinated, so if it bytes you, seek medical assistance.
|
|
|
Logged
|
|
|
|
jcromartie
|
|
« 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. 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
|
|
« Reply #12 on: April 11, 2008, 08:26:18 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. 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 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 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
|
|
« Reply #13 on: April 11, 2008, 10:47:38 AM » |
|
"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. BaronCid
|
|
|
Logged
|
|
|
|
jcromartie
|
|
« Reply #14 on: April 11, 2008, 11:38:22 AM » |
|
"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. :1 # VARx
vs. x = 1
and :Repeat(VARx=4) :[ :VARx+1 # VARx :]
vs. 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
|
|
« Reply #15 on: April 15, 2008, 11:00:36 AM » |
|
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 . That said I know I'll be using one for myself. 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
|
|
« 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 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: 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 ... 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
|
|
« Reply #17 on: April 15, 2008, 12:36:19 PM » |
|
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
|
|
« 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
|
|
« 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
|
|
|
|
|