Don't worry, I feel your pain. In the spirit of originality I'm writing my own tilemapper, and clipped edges and such are freakin annoying! Best of luck, my friend.

Edit: On the other hand, my tilemapper is really only going to be needed for some special effects and maybe a map. The meat of my game will be individual puzzles, so I should probably do those first and set my tilemapper aside for now.

magicdanw puts on his resolve face and goes to bed, hoping he's in the mood to code more tomorrow

magicdanw: Cool, glad to hear it. TheStorm: Come on, I know you can do this.

Hey Kerm, since you did some neat GUI stuff in DCS, you might know the answer to this question. I'm starting a basic GUI system of windows to make text alerts, menus, etc. easier throughout my game. I can save some of that information easily in the system stack, so that when you call the close window command it reads the relevant data off the stack and uses it.

However, I realize that this is kind of a hackish way to do things, and although it is faster than allocating memory in a TI variable, it could cause problems if two routines that store and retrieve data from the stack are called from different stack levels. I won't be doing this, because it's not nice, but does the TI OS ever do weird things like that in interrupts? Basically, what I'm asking is, is this "legal" or should I make my own stack in my own appvar?

Edit: As I'm making this gui more complex, it does indeed seem like it'll need its own stack. *sigh* I'll go dig out that developer guide for appvar editing bcalls.....

Holy hell, dude, just use Doors CS. It's going to make your life so, so much easier. That's why I made the GUI system in the first place. I was just working on the Password Protection SE for Doors CS today and was once again boggled by how much time I put into it and how much time it saves now when creating sweet-looking GUIs.

Edit: Full documentation is right here: http://dcs.cemetech.net/index.php?title=GUI_Tools

Your gui sounds great, but there are still some reasons I don't want to use it for this particular project:

1) I really only need the stack so that when I do open a window, I can close it and restore what was under it.
2) I want to get experience doing it myself. After all, it is a contest of our own abilities.
3) I want as many people as possible to be able to use this program, and Ion gives me the larges userbase.

Thanks anyway for the offer!

I hear that, but you're making life difficult for yourself. It took me an entire summer to fully develop the GUI, and I would assume it would take you a similar amount of time to develop such a system. If you use the API, all you need to do is an OpenGUIStack, a few PushGUIStacks, a mouse call, and then a CloseGUIStack. Text input boxes? Handled. Buttons/hotspots? Handled. Multiline/scrolling text? Handled. Custom pseudo-interrupt within the mouse routines? Go wild. I hear that you're trying to keep your userbase as wide as possible, but you're going to cut down your code size immensely if you use an existing API instead of a custom one, and you'll save yourself the hassle of recreating a chunk of what's already done.

Yes, I do that often
Mine's half done Remember, all I need mine do to is keep track of the data covered up by new elements. My tilemapper is handling rendering of each element as it's being created, and then when it's erased, the tilemapper pops off a few lines and pastes them back into plotSScreen. Simple enough.Most of that I won't need (or will use OS small text buffers for), and I planned on writing my own mouse routine anyway.

Fine by me, dig your own grave, I see your points. Oh, what about the argument about saving space?

I like my grave. It's got simple, fast gui routines that weigh in at well under 2kb (it'd be well under 1kb, but I'm including a sample full-screen image and a tilemapper-in-progress in that measurement).

Oh, I understand a bit better now. The only "GUI" things it's really dealing with is switching out the background and the foreground, except in multiple (ie, >=2) layers. Gotcha now.

Precisely. I'll also be using it a little later to deal with displaying a mouse cursor and moving sprites, so that it'll save the image behind the sprite and restore it afterwards. And now, on with the puzzles!

I move that the deadline for the contest be 11:59pm, Friday, July 25, 2008. All in favor say aye, anyone who objects, suggest an alternative.

Aye.

So far, 1 aye and 0 disagreements/suggestions.

Aye.

That makes it 2 ayes and 0 disagreements for a deadline of Friday, July 25, 2008. I'm keeping tally so that the topic keeps getting bumped and the rest of the contestants see this.

Yea!

Does that mean 'Aye?'

Yes, as in yea or nay.

So that's 2 Ayes, 0 Neas, and 1 Undecided. Lol.