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 - BlakPilar
Pages: 1 ... 44 45 [46] 47 48 49
676
« on: July 19, 2011, 09:16:13 pm »
@Ti-Programmer, could you explain more on what you mean by templates? It'll only support .8xp program files on the first release, if that helps. It seems like a good idea, though. As for the emulator, I might consider that for the first release, but I was thinking that might be able to be accomplished using a plugin (I'll contact the people who control Wabbit when the time comes). FTP shouldn't be too hard using sockets. I like that idea, people could easily work on the project with others. Thanks! 
@pianoman, get about 199 others to go for it and you got yourself a deal 
I thought this was an IDE at first...
Sorry...
But you could ask SirCmpwn to integrate this in his IDE, he might do it.
Its really useful for those who don't have roms.
Um... What? This is an IDE... IDE stands for Integrated Development Environment. Visual Studio is an IDE, SharpDevelop is an IDE; the concept is not TI-based lol. I don't want to ask SirCmpwn to integrate this; I want this to be a standalone IDE Besides, with lunixbochs's Python interpreter (we might have to port it to C#) there really won't be a need for an emulator. I understand how I could implement templates, though, so thanks for that! (I was confused at first because there really wasn't any need that I could think of)
677
« on: July 19, 2011, 04:25:47 pm »
I have one word about this: woah. Can't wait till it's done.
For making variables, do you mean using tokens that aren't used too often? If so, maybe dbd(? Perhaps int(?
678
« on: July 19, 2011, 03:57:19 pm »
Eh, computer programming isn't hard. Pretty much just logic when coding and figuring out how to do certain things. If you can program in Axe, you can easily make a transition to computers. With the interpreted languages maybe you could help out too... >.> I remember when Batlib and BASIC ReCode started out 
679
« on: July 19, 2011, 01:48:13 pm »
Well lunixbochs, I was thinking about it and my .exe engine is really a conversion-to-c# engine and I just use .NET's built-in assembling techniques to compile that converted code. I um... I kinda lied when I said I knew exactly what you interpreter did. You interpret what's going on in the program and execute it in Python? If that's it then yes, that's almost exactly my .exe engine. If we worked together, which would be awesome, we would have to modify that to execute the commands in C#, or learn more on executing Python inside of C#. The conversion, if we do that, or just using your interpreter shouldn't be that hard because I just added a direct-byte manipulation feature and I have a function that will convert a byte-string into a byte (i.e. "2A" will be turned into 0x2A).
680
« on: July 19, 2011, 11:03:16 am »
Thanks Qwerty! I have actually considered bytecode for this project, which would make the resulting programs cross-platform if I remember bytecode correctly? However, I don't know how I could access forms through bytecode compilation.
For math support, I fully intend to implement order of operations and as many of the math functions as quickly and simply as possible for speed. The only things I'm a bit iffy on are some of the "complex" statistics functions, such as T-Tests.
Calling external programs wouldn't be hard at all. I was also thinking about having the ability to port sub-programs for the on-calc versions into classes for the on-comp version and vice versa for more customizability, such as overloading.
681
« on: July 19, 2011, 01:28:10 am »
Ahh, I have tested it myself! I made a copy and tested it with and without getKey->K. The one with ran slower.
Frame speed or movement speed? That's the important part.
Movement speed. I haven't developed it enough for frame speed quite yet.
682
« on: July 19, 2011, 01:26:56 am »
That is where my .exe "engine" and my misc. come in to play. my entire project right now is simulating the basic interpreter, which sounds like what you'd be doing in your EXE engine. You could embed Python at this point instead of writing your own VM.
Yeah, you're right. Let me sleep on it and I'll think about how I can integrate it. Sounds fun!
683
« on: July 19, 2011, 01:24:02 am »
Ahh, I have tested it myself! I made a copy and tested it with and without getKey->K. The one with ran slower.
684
« on: July 19, 2011, 01:09:44 am »
Maybe I should clarify. Direct input goes off every frame. Testing getKey->K does not. This means that, if you're updating the position of ANYTHING, be it sprite, character or pixel, that thing will move every few frames if you're using getKey->K, and every frame if you're using direct input. I'm about 80% sure I know what I'm talking about.
I knew what you meant and I wasn't doubting your knowledge of Axe I was just asking lol.
685
« on: July 19, 2011, 01:03:01 am »
Hmm... Well, here was my original code:
Repeat getKey(15)
getKey->K
X-(K=...)+(K=...)->X
Y-(K=...)+(K=...)->Y
That ran almost at the same speed as BASIC. My new code is the same, but I don't store getKey to K and instead of (K=...), I use (getKey(...)). Now it runs extremely fast. 
Then your issue was probably key debouncing. Direct input [getKey(xx)] will fire every frame. getKey->K and testing K will fire every few frames because of the way that input routine works...if I recall correctly. Don't quote me on that, tho.
Regardless, getKey->K and testing K shouldn't be itself particularly slower than getKey(K). That is to say, the instructions shouldn't take much longer.
Wait... Could it possibly be different or help to know that I'm using sprites, not just a single pixel?
686
« on: July 19, 2011, 01:00:09 am »
Perhaps for comma based Disp's you could just write a new line?
I don't know Python, but in C# you could interpret
Disp "Hello","World"
as
Disp "Hello" + "\n" + "World"
right, but what happens when I do this?
Disp "Hello", 1
...
it sounds close enough to what you're doing, I still think we could work together (unless you have some really good ideas for translating BASIC's quirks to CLR)
...1.ToString() xD Anyway, don't mind me, I need to hit the hay soon lol. It's quite close to what I'm doing, and I would love for us to work together. The only "really good" idea imo is the accessibility to WinForms.
687
« on: July 19, 2011, 12:56:22 am »
you understand it'll be very hard to implement some of the quirks of TI-BASIC without an interpreter or specialized virtual machine, right?
But of course! That is where my .exe "engine" and my misc. come in to play. Also, like I said in my OP, not all commands will be supported (mainly the statistics ones, such as T-Tests), at least on the first major release; some may have different syntax, and some might do different things. Don't worry about me on that part  P.S. - If you look at the TBEXE "spoiler" in my signature, you'll see there are 4 parts that make up TBEXE. The .exe engine will take the longest, which is mainly why I haven't started it yet lol.
688
« on: July 19, 2011, 12:46:35 am »
Hmm... Well, here was my original code: Repeat getKey(15)
getKey->K
X-(K=...)+(K=...)->X
Y-(K=...)+(K=...)->Y
That ran almost at the same speed as BASIC. My new code is the same, but I don't store getKey to K and instead of (K=...), I use (getKey(...)). Now it runs extremely fast.
689
« on: July 19, 2011, 12:43:40 am »
Perhaps for comma based Disp's you could just write a new line?
I don't know Python, but in C# you could interpret
Disp "Hello","World"
as
Disp "Hello" + "\n" + "World"
690
« on: July 19, 2011, 12:38:25 am »
OH. Okay, now completely understand what you're doing. Gotcha. Wow, yeah, that's very similar to what I'm doing lol. I'm (de)tokenizing because TBEXE is also going to be a BASIC-IDE. Instead of directly interpreting the BASIC code like you are, I'm just going to see which commands will be needed, add them if they are, and convert the entire thing into C# or VB and use System.CodeDom, etc. to build that file into a .NET-based executable. Your idea is very nifty too
Pages: 1 ... 44 45 [46] 47 48 49
|
Show Posts