Omnimaga
General Discussion => Technology and Development => Computer Projects and Ideas => Topic started by: TsukasaZX on April 29, 2011, 04:49:08 pm
-
TI Basic in C with Gaming Orientation (TIBiC/GO)
TIBiC/GO is a C library that provides a TI-BASIC style "API" for game programmers. TIBiC/GO creates a setting that most TI-BASIC programmers will find quite familiar, and includes facsimiles of both TI-BASIC functions and powerful graphical functions found in xLIB and Celtic. However, it's not just straight up TI-BASIC-on-PC. TIBiC/GO adds a little extra "oomph" to the mix by allowing richly multi-color graphics, "permanent" data storage, the brilliance of sound, and much more.
There's actually a really good reason for this. As you know, working with TI-BASIC is a *great* way to get your feet wet in the programming pool. However, TI-BASIC is exactly that: basic. Real-world applicable programming languages are, quite honestly, nothing like TI-BASIC. They may share the same general procedural structure but TI-BASIC and languages like C or Java are worlds apart. Suffice it to say, it wouldn't be strange for somebody transitioning from calculator to computer programming to have a bit of a struggle adjusting. TIBiC/GO is designed to provide a sort of "training wheel" layer between TI-BASIC and ANSI C that gives programmers the comfort of TI-BASIC, a good taste of C, and the ability to go beyond TI-BASIC and into the world of true C programming whenever they want.
Originally just a concept, an idea, I'm actually going to be working on this alongside Yume (I'll be focusing on Yume more right now but during the summer I'll be splitting my focus 50-50 give or take). So far, I can confirm this for functionality:
- Akin to TI-BASIC, you will have access to 26 numeric variables, 10 string variables, 10 lists, and 10 matrices with having to hassle with declaration and initialization.
- Variables (or, more accurately, memory-allocated pointers) will be dynamically managed with simple function calls so the user never has to hassle with memory allocation. A simple function call frees all allocated memory at the end.
- You are NOT limited to the presets and can easily add your own. You may, however, have to do any scope or memory management yourself the hard way.
- Users have access to TIBiC/GO facsimiles of TI-BASIC functions like text(), Horizontal, Pxl-On(), Pxl-Off(), and Pxl-Change(); facsimiles of xLIB and Celtic functions like sprite drawing and tilemapping; and much more
- Easily integrate color and even sound into programs to go above and beyond!
-
O.O Allegro, right? This is an awesome project in my view. I hope we can write TIBiC/GO modules using C, that'd be cool.
This is one of those TI-Basic on PC projects, never saw one finished, so I'm hoping this one can go far :D
-
Yeah, I'll be using Allegro for the graphical aspects. I could write the graphical routines from scratch but then this library would take >9000 years to finish :P
I'll definitely be getting this finished and I think I can finish it in one summer assuming I have very few interruptions.
Also, for those wondering, my primary inspiration for TIBiC/GO was porting epic TI-8x+ games to the PC and playing them without needing an emulator and perhaps even upgrading their graphics and giving them sound. I also had an idea for a Steam-like application that let you browse these games, download and play them, and even submit your own. I call it GECGEAR (Graphically Enhanced Calculator Game Emulating Application for Retrogaming).
-
Sweetness!
-
Well, I guess if Freyaday thinks it's "sweetness" I *have* to finish it now ;)
I'm thinking 192x128 pixels as the standard window size (2x a typical TI-8x+ screen resolution). What do y'all think?
-
Well, I guess if Freyaday thinks it's "sweetness" I *have* to finish it now ;)
I'm thinking 192x128 pixels as the standard window size (2x a typical TI-8x+ screen resolution). What do y'all think?
I agree with such values for the resolution. How many colours? Or is it not limited as in 16million?
-
I'd say it's going to be pretty much true-color but I think, for simplicity's sake, I'll also include a handful of "preset" color options (e.g. "red" for #ff0000) for those who are hex code illiterate or only want a few simple colors.
-
*bump*
Gonna start listing (confirmed?) graphical functions for the sake of my own memory and to enlighten any curious folks. At this point, color related arguments are purely speculative. I'm not sure if I want to have a single hex argument or 3 RGB arguments, hence the color argument's lack of type.
Horizontal ( int y_pixel [, line_color] ) :: draws a horizontal line at the specified pixel on the y axis in the specified color (or black if unspecified)
Vertical ( int x_pixel [, line_color] ) :: draws a vertical line at the specified pixel on the x axis in the specified color (or black if unspecified)
Line (int x_start , int y_start , int x_end , int y_end [, line_color] ) :: draws a line from (x_start, y_start) to (x_end, y_end) in the specified color (or black if unspecified)
Tilemap ( int matrix[][] , int size , source [, TBD extra arguments?] ) :: essentially a clone of the xLIB tilemapping routine. Gonna have to fudge with passing arguments from a parent function to Allegro child functions or something to see how it will work. The 'size' argument is the size of each tile side so you could put 8 for an 8x8 or 100 for a 100x100 if you so desired it.
-
Don't forget to add error handling!
-
Oh, don't worry.
if (error) { alert_user_popup("You made a mistake you moron!"); }j/k
I can throw in some level of error handling but I think most syntactical error handling will be left to the compiler/debugger.
-
Well, yeah. This isn't Python. :P
But I think everything other than syntax errors should be recoverable
-
Well, yeah. This isn't Python. :P
But I think everything other than syntax errors should be recoverable
Define "everything other". I can't think of anything at the moment.
-
/0
Err:Data Type
Err: Invalid Dim
Err: Break :P
There's more, but I can't think of any atm
-
/0
Err:Data Type
Err: Invalid Dim
Err: Break :P
There's more, but I can't think of any atm
Zero division and data type are something best left to the compiler/debugger I think.
Arrays of any sort don't really have maximum dimensions and always default to 1 element so there's really no such thing as an invalid dimension in C or TIBiC/GO.
Heh, break.
Really, the question would be more or less why bother? TIBiC/GO isn't a compiler. It's a library. You compile it with whatever your preferred compiler is (straight up GCC, minGW, Code::Blocks, MS Visual Studio, etc). Even if the library provided error detection, what exactly would you do once an error is detected?
-
Do we need Allegro?
!
-
Probably, yeah.
-
*bump*
Legitimate TIBiC/GO library source code :P
void squirrel ( void )
{
char squirrel[] = "squirrel";
// Squirrel is now set to squirrel
}
Also, a friend of mine pointed out that window size should be larger because the pixels are somewhat .... smaller... on a computer than on a calc LCD. Should I increase the window size to some larger multiple of the 96x64 ratio or, for kicks, figure a way to use larger pixels? Or leave it alone?
-
Or just make us set the window size like good little boys and girls?
-
Due to the nature of TIBiC/GO, you're always able to do that. However, I still want default settings. More or less, I want standards that you abide by for things like GECGEAR or whatnot.
I dunno, I just think having some defaults to easily fall back on makes things easier for newbie programmers and would make it easier if I had TIBiC/GO contests or built GECGEAR.
-
[Partially edited Cemetech crosspost]
I have confirmed that the color argument will be "char hex_color_value" but users can implement predefined color names such as "red" for #FF0000.
Currently, I've decided that users can set the window size to one of two defaults, COMPACT (384x256 pixels) and NORMAL (768x512 pixels), or a custom pixel size. Note that both defaults are multiples of the 96x64 pixel resolution of the TI-8x+ calculators
I'm throwing away the "larger pixels" idea because this isn't supposed to be a 100% conformist port of TI-BASIC, heheh.
Also, the TI large and small fonts will be replicated and made available as the default fonts. Can't beat the classic fonts ;)
-
feel free to use/modify this if you need a spritesheet of that font. It doesn't have every single char and somethings might be better in different locations on it, but it might be of use.
(http://i534.photobucket.com/albums/ee348/Miotatsu/Font.png)
-
Thanks, Mio! This will most definitely come in handy :)
/me gives Mio a cookie and a little hat for such awesome assistance.
-
Hmm I'm not sure if I understand, but I assume this is kinda like to have TI-83+ BASIC as computer language? It would be nice. It kinda reminds me http://ourl.ca/6973 and Miotatsu's BasiC++ projects, although I think the former was dependent on FreeBASIC and the latter never got released.
-
It's kind of like Mio's BasiC++/ATI-BASIC, however there are some slight differences:
1) TIBiC/GO will have xLIB/Celtic-based functions with their own names, so there won't be abuse of real() and whatever it was Celtic used. You'll have stuff like DrawSprite() and TileMap()
2) Color!
3) Sound!
4) Multiple buffers!
5) Rick Astley! -- err... I mean custom fonts!
6) The ability to throw in pure ANSI C whenever and wherever you want!
and much more! :D
-
5) Rick Astley! -- err... I mean custom fonts!
Don't forget the rickroll function lo.
This project sounds nice, and it looks like it has been making some good progress
Will this be able to run with the exact same code as calcs(TI-84's) or would we have to rewrite it?
-
You'd have to rewrite it. It's not meant to be a literal port of TI-BASIC to the PC or a TI-BASIC emulator of any kind. Rather, it's more like a wrapper that gives TI-BASIC familiarity while still programming in C.
For instance, you can't do
10->Ayou'd have to do:
A = 10;like actual C, and conditionals would require the traditional '==' instead of a single '='. Furthermore, you'd still have to do things like declare a main function.
-
Cool to hear TsukasaZX. Also will we be able to choose our resolution? It would be nice to be able to have full screen games but pixelated like SNES ones or high resolution, depending of if we want old skool stuff or not. If it's just stretched up, it would be nice if there was no blurring like Game Maker either. :D
-
You can change the window size but that's about it. Pixels will be typical LCD pixels. If you want things to be big and pixelated, you'll have to make your graphics look that way.
I don't really know how to go about doing full screen and graphics upscaling and all that jazz X_x
We'll see when I make more progress, whenever that happens to be. I have a fairly busy schedule at the moment.
-
I made something similar to this in FreeBasic like DJ Omnimaga mentioned in his post.
I'm very interested to see how this will turn out!
-
Nice to see you again coolsnake. Yeah I remember those projects. Unfortunately Tsukasa project died I think, though, noticing the last post date and the fact he didn't post anywhere else for a while. :(