Right now, the title screen is really making me mad. I try to put the picture data in a DispGraph([HEX]) command, because Im only using it once. Like this:


Code:


My impulse was to use getKey(9) as a way to detect if the person pressed ENTER. However, the title screen doesn't display it more than 0.001 mS.

Another thing: What exactly do the different buffers do? There's the DispGraph, DispGraph^^r, and DispGraph^^r^^r. Is each one like an overlay? How can I use them to my advantage?

getKey(9) isn't a blocking key routine, so it's just checking in that instant and then going to the next command, hence why the title screen doesn't display. You'll need to put it in a loop or use a blocking key routine (I think getKey^r).

The command list is your friend!

merthsoft is absolutely correct about the key detection part; I would suggest using getKey in a loop or just using getKeyʳ.

DispGraphʳ is for displaying 3-color grayscale and DispGraphʳʳ is for displaying 4-color grayscale. For those commands, the main drawing buffer (automatically drawn to with all drawing commands) accounts for the high bit of the color and the secondary drawing buffer (drawn to by appending an ʳ to pretty much any drawing command) accounts for the low bit of the color.

Thanks! I don't plan on using greyscale in Ballistica, but I might to distinguish the different axes drawn.

The main engine for Ballistica, I don't think I'll have too much trouble with that.

What I WILL have trouble with is the graphics. I plan on using a GUI to input data you enter in little textboxes. How would one make a "textbox" on a "window form" with Axe?

Is this a contest entry, or otherwise targeted for DoorsCS? If so, AxeDCS (some documentation here) would probably make your life significantly easier by allowing you to use the GUI API. That's really the only GUI library that I know of (and it's quite a good one). Otherwise, you have to code the UI elements yourself.

Oh my god, thank you!

I didn't know that existed.
Ballistica was originally a contest entry, but I doubt I have the skills to get it finished on time without further help.

I know Im not supposed to double post but:

There's a sprite on the main screen controlled by the arrow keys. When the user presses [2nd], a point is put at the cursor's center in the memory and you can then launch/whatever.

Is there a way to move the cursor around without having to clear the screen every time it moves, to put the cursor in its new position?

One simple way to draw a cursor is to draw the sprite using xor logic (the Pt-Change() command in Axe). When you want to update the screen, draw the sprite both immediately before and immediately after the screen update. The first time will draw the cursor and the second time will "erase" it, because you will have xor'ed the same data twice.

Also, why are you talking about "clearing the screen" ? You don't need to clear the screen, you can just clear the buffer, redraw everything and then update the screen, and the screen never was cleared. That is not an optimized method speed wise but since you are just moving a cursor, you don't need speed. Basically, your code would look like this, in pseudo code :

While 1
Draw the background on the buffer (basically a Copy I guess), that erases the cursor
Move the cursor position
Draw the cursor (those two commands can be put in one)
Pause, if the loop is too fast
DispGraph
EndIf getKey(54)

And for your textboxes, why not using some Rect() and RectI() routines ? It is not really hard to get a textbox if you can draw rectangles.

Thanks guys.

BallistiCa is going well, and the GUI is proving nearly trivial with the AxeDCS axiom. Of course, it will be sort of a pain, because one will need Axe to run the compiled program. Hopefully, when Im done BallistiCa, I will rewrite it to a true noshell program (rewrite in assembly would be glorious, but I don't need to get into that right now)

Did you mean "one will need DCS to run the compiled program" ? I don't see why a compiled program would need the compilator (except if you compiled in Fusion mode).

The readme file for the AxeDCS axiom made it clear that one will need both Axe 1.2.0 (at least) as well as DCS 7.1.1 (at least) to run any program with that axiom. It is definitely a limitation, but given that DCS takes up 3 app pages (and so does Axe IIRC), even the Ti 83+ will be able to hold it.

My new fear is that BallistiCa will be too large for a "standalone" assembly program. It may have to be compiled and signed as an app. However, I took most of that problem out by removing unnecessary picture data (I don't really need a titlescreen on a program, the most I should do is an about window).

Maybe I missed a part of the readme, but I read that :


So DCS is indeed needed to run the prog, but Axe 1.2.0 is only needed to compile, not to run.

Nope, Axe only takes up 2 pages.

Why not keep it as a Doors CS program? The whole point of all the libraries in Doors CS is that they allow you to make your programs much, much smaller, given that most of your users are probably already running Doors CS. Also, you can have ASM programs running under Doors CS that are up to about 20KB or larger; you just need to make sure the code is all within the first 8KB and the remainder is all data.

That is the problem. I already said that several times, but I know a lot of 83+ users who still run MirageOS to save space because they don't need more (they don't need xLib, Celtic, PicArc and other basic libs for example).

(From the point of vue of those MirageOS users, a noshell program is not really better since MirageOS doesn't run noshell programs, but it is not really hard to compile as a Ion program too once there is no dependencies).

Unfortunately, things made with the AxeDCS axiom need DCS 7.1.1 at least to run. The hooks are not MirageOS hooks, they are GUI hooks directly integrated to DCS. Thus, MirageOS will be useless in running the program.

Because DCS is already necessary to run the program, I'll compile for DCS. The readme file has told me that I need this huge program header on BallistiCa (but I found that was not actually necessary), and I've also found that if I compile for DoorsCS, the AxeDCS axiom hooks will still work.

Of course I know that AxeDCS needs DCS to run. I started talking about MirageOS after you talked about making your program a true noshell program.

Back in the days, people just compiled two versions of their programs: One for Ion and one for MirageOS. In some rare cases (eg Galaxian. Ztetris caused a RAM Clear on exit), Ion programs could be ran fine with the Asm() command, but Ion programs appears in every existing shell.

I personally prefer DCS by far, but on my 83 Plus I still use MirageOS because I always run out of archive. However, if GinDiamond makes his game a DCS program he'll take full advantage of that shell, as Kerm said. I guess it's up to him.

Also not to nitpick too much, but you should maybe say "no shell" or "nostub" rather than "noshell", because there's an actual shell called "Noshell" (by BrandonW) and it might lead to confusion.

What the heck is going on with this code? I compiled it today with no changes with the last compilation, yet it exits as soon as it starts.


Code:


I have a feeling the Return is doing something. Am I right?

You don't need a return or an end because a return signifies the end of a subroutine and/or the program. Axe will automatically add the return. an end is not necessary.