This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Hayleia
Pages: 1 ... 109 110 [111] 112 113 ... 239
1651
« on: February 22, 2013, 12:22:18 pm »
How do you store an entire list in AXE as an appvar?
not {L1} but the entire L1
By the fact you said "list", I fear you haven't unserstood the difference between "pointer" and "variable". Anyway, here is a working code.
"appvNAME"→Str0
GetCalc(Str0,768)→A
!If
.the appvar was not created, maybe you don't have enough RAM
.in this case, maybe the program should exit safely instead of copying random bytes to a random place
End
Copy(L1,A,768)
.you can unarchive the appvar here if you want
Of course, if you don't use the full 768 bytes of L1, you can make a smaller appvar and copy less than 768 bytes. edit For a complete tutorial on how to use appvars (among other things), see this tutorial and give +1s to FinaleTI 
1652
« on: February 22, 2013, 11:24:06 am »
But lol, do they really think someone will pass all his/her life on an emu without buying the calc ? I mean, if you don't buy the calc, you are not interested in calc, so you don't emulate it. And if you use an emulator, it is to code things for your calc without fearing to crash it, or to try a calc that you will buy.
They are just preventing potential customers to try and buy their products, and customers to profit from their already bought device.
1653
« on: February 21, 2013, 01:00:13 pm »
If you want to compile a program that is larger than 8192 bytes, you can Also use CrabCake instead of compiling as an app. There is also Fullrene that should do the same as CrabCake but for some reason I couldn't figure out how to make it work so I sticked to CrabCake.
1654
« on: February 21, 2013, 12:27:26 pm »
I never quite understood why TI added lowercase support to their calcs, but made it so most normal users can't enable it.
In fact, they "made" it so most normal users can use it since they are enabled by default when you buy a calc (at least they were enabled when I bought my calc, without me installing anything). But one RAM Clear disables it, and this is where TI was stupid, forgetting to put a way to enable them back, hence why programmers need a way to reenable it.
1655
« on: February 20, 2013, 12:06:15 pm »
1656
« on: February 19, 2013, 12:43:12 pm »
A sprite-test detection ?
A text test is a sprite row test so one implies the other. 
True story bro. But that doesn't work for the line and the circle. This is why I really think that sprite test detection is much more likely to happen than arbitrary geometry forms detection (not sure about the meaning of my sentence). edit nevermind my post, I got ninja'd by Xeda whose answer is surely more accurate
1657
« on: February 19, 2013, 12:39:28 pm »
What about a real-time battle engine instead of a turn-based one ?  That would be awesome in my opinion (but certainly a lot harder to do  ).
1658
« on: February 19, 2013, 12:37:36 pm »
People, you don't know Samos.
Where he is, all the conversations are changed into troll, spam, etc... 
That is exactly why I said that he forgot about trolling and Gangnam Style. I was not joking 
1659
« on: February 19, 2013, 12:35:55 pm »
Do you think it's possible ? Grammer would innovate, with Pixel-tests, Line-tests, Circle-tests, maybe Text-tests !
If it is, can I suggest one level more harder again: A sprite-test detection ?
In fact, I think the sprite test detection would be easier to do than the other detection o.o For exemple, in Axe, you have Pt-Get (which "extracts a sprite from a buffer", if I can say so) and Equ>String (which compares two strings), and a good use of a combination of both can give you your sprite test
1660
« on: February 19, 2013, 12:31:26 pm »
As far as Language levels are concerned:
*Axe is as low as you get without BEING assembly. It barely has function support.
*C is one of the lowest level languages you will see on the computer. Most compilers even allow inlined assembly.
*C++ is stupid for this list. It's C with Java attached, and it shows.
*TI-Basic is interpreted. Badly. It also doesn't have enough features for me to give it a decent "Level", as it has no Object oriented anything, no functions, nothing a programmer would WANT in a High Level Language. However, it also abstracts ridiculously from the assembly it takes to run it.
I agree with Axe and don't know the other languages But that post is still interesting for me to know which language I am most likely to choose if I ever want to program for other things than calculators
1661
« on: February 19, 2013, 01:14:58 am »
Yeah, I was also thinking that headers should be defined now. Especially if shells want to add backwards-compatibility, there should be a header indicating that the program should be launched in a special way to make it run like on a monochrome 84+ (if you understand my sentence).
1662
« on: February 19, 2013, 01:12:59 am »
Actually, immediately jumping into Axe isn't a good idea, unless you've done a lot of programming in the past.
On the contrary: if he doesn't learn Basic before Axe, he won't get pointers and variables messed up in his head Don't learn assembly first. At least learn Axe before that.
On the contrary: ASM is only hard to learn when you are used to "easier" languages but is said to be easy from people who learnt it first So it depends on what you want to do. If you want to make advanced games, I'd suggest to start ASM. If you want to make advanced maths, I'd suggest Basic. If you want a bit of both, I'd suggest Axe.
1663
« on: February 19, 2013, 01:07:55 am »
I am not talking about complexity but about calculating in calculations. You will never be able to write this in basic:
Line(8,+1→A,,*2)
In Basic, you'll have to write:
9→A
Line(8,A,A,A*2)
Psh, in BASIC you just do:
9
Line(8,Ans,Ans,Ans+Ans
True, but then, you didn't store 9 to A (even thhough that would only recquire one more line).
1664
« on: February 18, 2013, 03:10:29 pm »
And Hayleia I would say Axe is semi high level, because it has several commands that have identical syntax (or close) to TI-BASIC, which is an high-level language. In 2010, I wrote a screen inverting program using pxl-On commands that only required swapping X and Y coordinates around and adding an Axe header in order to be compilable. At the same time it is low-level too because of the whole pointer access and how much control you have on the RAM. I would say it's a mix of both.
Well in Basic, you can't even do 2→A→B while in Axe you can do this:
Select({BB^8+GDB0},→{Q+++AA^64*12+(BB/8→r3)+L6→}) xor |pi|11111111
→{r3-11??r2-11,r2+1}
Yes it has structures but not immuable structures, optimization is still very possible and there is a lot of liberty
(edit: sorry if my sentences mean nothing)
Some TI-BASIC code by Weregoose (I think someone posted code on IRC or a post somewhere once) looks even more complex 
I am not talking about complexity but about calculating in calculations. You will never be able to write this in basic: Line(8,+1→A,,*2) In Basic, you'll have to write: 9→A Line(8,A,A,A*2) And Hayleia I would say Axe is semi high level, because it has several commands that have identical syntax (or close) to TI-BASIC, which is an high-level language. In 2010, I wrote a screen inverting program using pxl-On commands that only required swapping X and Y coordinates around and adding an Axe header in order to be compilable. At the same time it is low-level too because of the whole pointer access and how much control you have on the RAM. I would say it's a mix of both.
^ That.
IMO, Axe is a lot closer to C than asm because of its syntax and ease of use. OFC, you have a lot more control over RAM, but that's because on a multitasking computer, you can't mess with stuff a lot 'cause you may cause a general crash (btw C has pointers). On calcs, your program is the only process that's running, and even then you can't mess with the OS data unless you know what you do.
"Ease of use" depends on what you are doing For example, with nikitouzz we challenged ourselves to make an optimized code, and we had to never use any command that is "easy of use", only elementary commands. This is where I got the previous line from (with the Select).
1665
« on: February 18, 2013, 01:24:45 pm »
On the other hand, there are most likely examples where ASM programmers will find it harder to do in high-level languages than ASM, but high-level language programmers will find the same thing harder to do in ASM. In some cases it depends of mentality or preferences really and what you have been used to for years (eg if you never programmed in TI-BASIC and jumped straight to Z80 ASM, you might find TI-BASIC code structure nightmarish). This is why some people claim that ASM is easy to learn and use even though many people have tried hard and failed, and of course there are people who say BASIC is easy to learn and use even though others found it a major pain in the butt to use.
In conclusion, both low and high level languages are vexing, but in different ways
True all of this And Hayleia I would say Axe is semi high level, because it has several commands that have identical syntax (or close) to TI-BASIC, which is an high-level language. In 2010, I wrote a screen inverting program using pxl-On commands that only required swapping X and Y coordinates around and adding an Axe header in order to be compilable. At the same time it is low-level too because of the whole pointer access and how much control you have on the RAM. I would say it's a mix of both.
Well in Basic, you can't even do 2→A→B while in Axe you can do this: Select({BB^8+GDB0},→{Q+++AA^64*12+(BB/8→r3)+L6→}) xor |pi|11111111 →{r3-11??r2-11,r2+1} Yes it has structures but not immuable structures, optimization is still very possible and there is a lot of liberty (edit: sorry if my sentences mean nothing)
Pages: 1 ... 109 110 [111] 112 113 ... 239
|
Show Posts
