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 - Streetwalrus
16
« on: March 20, 2018, 06:35:13 am »
I might even make my own!
Eventually! I have things I could talk about in the future, but right now they're not quite public-ready. @Streetwalrus : I've noticed you've been around a bit and posting. Nice to see you here again. I usually seem to miss you in IRC, though I don't spend an awful lot of time there these days.
Thanks! Hopefully we can catch up. I'm usually available between 10am and 3am (GMT+2). Just highlight me if you want to talk.
17
« on: March 20, 2018, 06:02:17 am »
It's a shame that AoC is the only one who has replied to this thread so far. I'll admit that this doesn't appeal much to me (at least in its current state), but it's clear that you're putting in a lot of effort to make something good, so I'm still rooting for you. 
18
« on: March 19, 2018, 07:01:49 pm »
Also, why do you only need 768 bytes for 6144 pixels?
Each byte is made up of 8 bits. Since the display is purely monochrome and doesn't support grayscale, you can store one pixel in each bit, and 768*8=6144.
19
« on: March 19, 2018, 07:00:11 pm »
You can use zstart, which lets you edit archived programs directly.
20
« on: March 19, 2018, 09:08:45 am »
I whipped up a quick website for TI-Boy CE, nothing too special yet but it'll be nice to have when I release the emulator. I may eventually (after release) write a series of blog posts about TI-Boy's design, if anyone's interested. I'd love to read about it. It's not quite Spring yet, but soon... 
It's already 32°C over here. 
21
« on: March 18, 2018, 07:47:20 pm »
I don't think there is such a restriction. Just do GetCalc(tmpTEMP, size) and you're good.
22
« on: March 18, 2018, 07:23:14 pm »
Not to hijack this thread, but I guess I'm also kinda back? I'm not actively watching the IRC channel but you can poke me on there if you feel like it, and I check the forums every few days as well.
23
« on: March 18, 2018, 07:21:55 pm »
I always use GetCalc(appvTEMP, size) for dynamic variables. (This creates an appvar called "TEMP" of the given size and returns a pointer to it.) Just remember to delete it later.
I'm pretty sure there's a type of variable that gets deleted automatically by the OS when you exit, it's called tmp and it replaces the w token (2nd+9).
24
« on: March 14, 2018, 02:28:39 pm »
I would handle the sprites more or less like strings, where adding them would concatenate them into one. In the very specific case of z80 calcs where we mostly handle 8-wide sprites, stacking them on top of each-other seems like the most straightforward way to do it.
25
« on: March 14, 2018, 02:25:55 pm »
And that's extra effort. Though there is probably a performance advantage to accessing that data through statically computed pointers than from an unpredictable memory area. You shouldn't need to do anything at the start of the program either, just reset those arrays before exiting.
26
« on: March 14, 2018, 06:03:37 am »
Xeda pretty much summed it up.
Note that I would not recommend creating buffers within your program, as most shells will write that data back to the actual program file and to archive when the program exits. That is in most cases not desirable: saving temporary data that you will erase later is wasteful, and you could end up with unpredictable initial state in your program because of that. In some cases you might want to use this for saving the game, but it's just better to make your own appvar for that.
27
« on: March 08, 2018, 05:41:24 pm »
The legend himself comes back to deliver. This looks pretty awesome.  coca cola is for plebs tho, dr pepper is the drink of the chosen
28
« on: March 08, 2018, 05:05:58 pm »
##6/2(1+2) =\ 6/2(3) =\ 6/6 =\ 1##
##\frac{6}{2(1+2)} =\ \frac{6}{2(3)} =\ \frac{6}{6} =\ 1##
This is due to how their division works. It's a fraction, not the ÷ symbol. So its 6 over 2(1+2) not six divided by 2(1+2). The way that TI-OS does it there is wrong according to that.
##6÷2(1+2) =\ 6÷2(3) =\ 3(3) =\ 9##
If we aren't treating it as a fraction then it is correc according to standard order of operations.
TI calculators interpret this just like any other interpreter or compiler would, it's CASIO that is wrong here. It's the only way that makes sense without natural expression display. The only difference is that the * operator is implicit. This is how Python 3 does it: >>> 6/2*(1+2)
9.0When in doubt add more parentheses to eliminate the ambiguity.
30
« on: March 08, 2018, 04:49:34 pm »
ASM isn't very hard to learn, but if you want to do anything interesting with it, you need a good understanding of how the CPU works. Axe simplifies things a great deal by providing a ton of convenience functions for the most common tasks. Makes things much easier than building from scratch in ASM.
Also, assembly isn't necessarily faster than Axe, but if you are really good at it, then you'll be able to write smaller and more optimized programs, and it's quite fun.
|
Show Posts