Quote from: Compynerd255 on June 15, 2011, 04:02:47 pm

Quote from: ralphdspam on June 15, 2011, 03:46:34 pm

Wait, what?  I don't get it.

It's a meme.

But what part of the program is this? Is it the map, is it the title screen, or is it the actual program code?

Code.  At this point, there is no data.

What happens when you execute this particular piece of code?

This is how I first reacted when I read this:

I think that someone should compile a list of all the CEOs and calc directors at TI, and see if changes in leadership have anything to do with what the code is. I suspect that TI's ambivalence might have to do with CEOs having different priorities.

One thing I also think about with these malicious attacks is that, although we are a minority of calc users, we are the Coders of Tommorow - their future employees. In today's time, there is a shortage of computer programmers (at least I think there is). TI wants to protect against hacking and exploitation, but they don't realize that there are plenty of programmers out there who got their start on hobbyist devices such as calculators. They need programmers to work their new devices, and if they defeat programmability, they are only defeating themselves.

We also have to remember that if there is a will, there is a way. TI's first offerings were not easily programmable, without native ASM support. The previous generation of TI programmers, with greats such as Joe Wimbergule and Sam Heald, were able to hack the 85 and bring ASM to the TI, which had influenced TI's decision making for the next several years. Now we are in the second generation, and TI is mounting their defenses again. They did it once. We can do it again.

I just looked at the documentation for that, and it looks very promising. I don't have to buy cards! The only problem is that it seems like a somewhat buggy trust thing (it only moves and obeys cards, it doesn't actually apply the rules programmatically).

EDIT: Raylin, the link to Phantom Sanctuary in your signature is broken.

EDIT 2: I just got this program to work on my system, and it is pretty cool. I can't wait to start playing games with this!

I just watched the video, and that looks FREAKIN' AMAZING! I'm going to try this as soon as possible! Great job, Aichi!

Okay. This is really cool!

This project has a lot of great potential. I hope you go far with it. Be sure to add Star Power!

With regards to sound, I think that having a two player battle mode is far better than simply adding sound, because people could just be asked to play the MP3 at the same time.

I think that you should just define it before you use it. That's the best solution for calc. There isn't a reason why you would extract the defines into a seperate program, except that it wouldn't get backed up.

The reason why they would put the defines at the bottom is because they don't want to scroll through them. So, I think that we need to do one of these two things:
- Allow jumping to a label/define when editing, so you don't have to scroll through the data or preliminary code.
- Create an alternate version of the editor with code folding. In code folding, you look for all of the definite code blocks (If-End, While-End, Lbl-Return, etc) and let people use a key to hide them, replacing them with a little plus thing. They can then press a key again to expand the block again.

Usually, whenever you write a routine that can be used in multiple programs, you code it in such a way that it can be used as easily as possible, without restricting where people can store things. In Axe, you write a subroutine and have it accept arguments, like so:
sub(SUB, EXP1, EXP2, ... , EXP6
In this code, EXP1-EXP6 are loaded in the variables r1-r6 (the Polar variables), respectively. Then the subroutine is called. You can use this to pass up to 6 values into a subroutine.

I also looked at your collision code, and I see serious flaws in the logic. Below is a piece of code that should function the same as the second chunk in your code (the collision between the two sprites).
If sub(COL, {0+L1}, {1+L1}, Pic1, {2+L1}, {3+L1}, Pic1
40→D
End
Lbl COL
If abs(r1-r4)<8 and (abs(r2-r5)<8)
.So that we can use the same For loop no matter how the sprites are positioned, we will flip the arguments if Sprite1 is higher up than Sprite2
If r5<r2:Exch(r1º, r4º, 6):End
.Count up the sprite rows
For(X1T, 0, 7
.Now, we will take the first potentially colliding row of the first sprite and bit shift it so it is in correct space with the second sprite. We will bitwise AND that result with the second sprite. If the two sprites share a pixel at that location, the If statement will become true.
If {r5-r2+X1T+r6}*e^(r4-r1) and {X1T+r3}
.Pixel Collision Occured
1:Return
End
End
0:Return
The actual per pixel test logic might not be accurate... Please correct me.

Thank you for bringing this up, BTW. I might use this myself in my next project.