Post updates on your projects here, or give other authors your feedback on their works in progress.

When posting about an upcoming program of yours, please include a link to any relevant information (screen shots, etc.) in the URL field.

To have an entry removed, please Contact Us.

i am making this euchre game for the ti-89. and i need help, LOTS of it. please, if anyone would like to help me, i would appreciate it. i am a pretty basic programmer. i have gotten a little far, but i just need someone to help me out in the places i need. this would be greatly appreciated. my e-mail is gamesandmusic2@cs.com, or viedogamer911@home.com, thanks a bunch if you can help!!

I can help. I am a very experienced BASIC programmer. What do you need?

Recently I got more time to waste looking up information about programming games for my TI-89 and took the time to download/begin using tigcc... I must say it's great because I *hate* assembly but I am an advanced c/c++ programmer so...

I am in the process of making a civ-type game for the TI-89.

I don't expect many difficulties along the way, since I made a C clone of civ for DOS a couple of years ago and still have the source, so this should be relatively fast =)
The only concern I have is how fast the TI-89 will run out of memory, I'd be willing to take any advice from experienced TI-89 programmers about how much memory I should be using.

Most C users on the TI89 use Dynamically allocated memory so that they can use the memory and then free it up when the program is done. However even after this most exceptionally good programs, like TI-chess and Alien Invasion, are around 10,000 to 20,000 bytes. Look at alloc.h in Zeljko's Documentation for more.

Oh yeah, and except for me (and the whole 3 other people) this board is unused. I think that it should be more noticed. *sigh*
So that my be all the help you get.

Well I'm now done with the basic engine mechanics (determining what of the terrain you see, drawing terrain, drawing the cursor, etc)... just as I said, that was pretty fast, took a total of around 2 hours.

At this point I have two questions... Would it be better if the cursor remained at the center of the terrain that you see all the time (like in side scrolling games when it stays fixed on the central character), or moved around the visible area and the visible area was only scrolled when it reached one of the sides?

Second question... Any TIGCC programmers out there know about how to implement double buffering? I've noticed that you pass the plane on which you perform the operations to the SpriteX functions, and I've seen the BUFFER in graph.h, but I haven't found a function that copies the buffer memory to the screen.

As an alternative to double buffering, I could just not clear the screen and instead AND a blank sprite with the memory in question and then XOR (or OR) the terrain graphic with it, doing this one terrain square at a time, however, that would be slow compared to building the entire image in memory and then copying it to lcd memory.

Try memcpy, I do not know where it is though *opens documentation*. Oh its in the mem.h header. You could also use LCDRestore, which is probably more efficient.

I've been trying to implement a dialog box with one request item that will ask for what the player wants to name the city he is building. I've looked through dialogs.h, and even though the documentation is usually nice, it left unclear where the string from the request item will be stored/how to retrieve it... Anyone with experience in using dialogs.h is welcome to help me =)

Try popupaddtext while declaring the dialog.

At some point after April 12 I will create a website for this game with any info/news, I'm going to be very busy until then though.

BTW, did my comments help you, or did you totally ignore them? Can you help me now, all I need to know for my game is how to make maps and collision detection, can you, or anyone else, help me with this.

Sure, I heard you, your comments helped me... thanks =)

Please tell me if you are writing your game in C or ASM, I can answer you if you're writing your game in C, otherwise someone else will have to do it.

Of course it is in C, how else do you think I was able to help you. Can you help me now.
:) (:

Strange, it won't post... maybe it's too long or something. Give me your email address or another forum that you go to, I'll send/post it there.

You could have clicked on my name, *sigh*.
E-mail:
yoshi9877@cfl.rr.com
So what, I like nintendo.

I've made a very rudimentary site so I can post screenshots, if you're interested in seeing them, click on the link in the Web Page field.

Wow. Seems like you're making pretty good progress! The screenshots were awesome, I look forward to seeing the complete game!

"nosnibor", that is "robinson" backwards. That is interesting.
:)
I liked the screen shots too. Is this going to be like the command to conquer game?

I've played the Command to Conquer game recently, and yes this game will be in some ways similar to it, but in other ways different.

The civ game I'm making will include a very large map (an area of anywhere between 16 and 64 times the area of the visible screen). It also should include cities, science, terrain alteration, and diplomacy. For this reason I'm not sure how large the game will be and whether I'll have to dumb it down in any way for the calculator to be able to handle it.. oh well. CTC is centered around the construction of your base, on a map the size of the screen. Combat will be handled differently, in my game it will be like in civ where you move your unit onto an enemy unit and they start beating the crap out of each other, but I will not include hps because of memory considerations. Production is not simply a matter of spending the resources your miners have collected, cities take time to produce improvements and units. If you've played civ and any real time strategy game (such as any of the command -and- conquer, warcraft, or age games), you should be aware of the differences already. Both are fun.

That said, both games are turn based, hopefully my game will be as fun as CTC is (I play it every day when my own unfinished game doesn't give me some kind of new error 1st period), and CTC gave me the idea to use the backspace key to end the turn =P I will probably also use inverted graphics for enemy civs (of which there should be up to 6 + 1 barbarian player), since I can't think of anything better.

CTC pretty much made me interested in trying to install TIGCC again, this time it worked so now I'm on a roll. So thank you Ty Taylor.

I'm getting a lot of errors that seem completely unrelated to my code and happen spontaneously. Illegal instructions, protected memory violations, etc. Since most of my previous programming experience is for computers, I may just be unaware of some nuances of calculator programming, but on the other hand these could be bugs with the latest version of TIGCC.

If anyone could please clarify why these seem to occur for no reason and inconsistently?

most likely, you are trying to define and use stuff that is already defined, this happens most when you are using "tigcclib.h". Always assign very creative functions and variables. You may also have () problems. Always check the FAQ, it should help a lot.

That didn't work, instead of including tigcclib.h I included only the 5 files needed for my prog (which did lower compile times, as expected)... however I still get Address Errors etc. If the problem was in a #define, the game would behave very strange, but it doesn't. Most decent compilers have a way of warning you when you declare a function of the same name as one that has been already declared, so I doubt it has anything to do with the naming of my functions, besides they all work fine. So I still get the errors and I don't know why.

Also, for some reason initializing a char* buf=NULL at the beginning of a function and then attempting to use it in any way at all gets me a protected memory violation. Calculators=weird.

You... must... look... at... the... documentation... It is the TI C programming bible! You can not do ANYTHING correctly without THOROUGHLY examining the manual, can you. This is not big computer C. This is TI C. You need to look at the FAQ especially.
For the NULL problem:
A) NULL == (void *)0;
B) I do not understand why you would want to do this anyway.
C) NULL, H_NULL, HS_NULL, etc. are all typecasted zeros going to handles stacks and other junk. If you want to test to see if something returned NULL you could see if it returned ((void *)0) or you have to search it in a special way with dereferencing operators and a whole bunch of other crud. Try reposting at the webpage above to get answers from experts like Kevin Kofler, Zeljko, Thomas Nussbaumer, Sebatian Reichelt as well as many other guys, I hang out there too you know. I recommend it for answers to help questions since many (some helpful, some not, and some weirdoes) people hang out there ready to give assistance when they can. KronicDeth is probably the non-famous person that helps the most, so ask him especially, and SAY THAT I SENT YOU, that way I earn brownie points.
Some of that was funny, some of that was informative, some of it was stupid, but remember, it is ALL true, I think.

lol... actually, I pretty much read/searched for everything that could possibly have anything to do with the problem, including reading through all of the #includes in my prog and the entire FAQ, and I haven't found the answer. So don't assume that I haven't.
A) either that or just 0L. Actually, most people already know that, so you didn't really have to point it out
B) I'm doing it to avoid the annoying warning and to make sure that that isn't what's causing the problems.

If they are just stupid warnings, forget it, my program has 16 warnings by default and I KNOW them to be benign, they are warnings, not errors. Also, if you know what NULL is, why don't you just check for the actual value, it is the same thing.

Alright you do not have to teach me -- I also know that these are routine warnings, and I ignore them. I said they were "annoying" thats all. I wouldn't have a problem with them if IDE didn't immediately go to that line, because then I have to go back to the line I was testing a change on, and that's a major pain with a (relatively) huge program like what I have right now.

HEADER FILES, you now no longer have hyper huge code.
:)