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 - Vogtinator
Pages: 1 ... 31 32 [33] 34 35 ... 83
481
« on: April 28, 2014, 05:43:27 pm »
I was going to suggest exactly this. Keep in mind that (I believe) a lot of people are happy with the original 16px textures, and with those you could have copies of one texture for all 16 light levels in only 8KB. Of course, if you implemented this for all block types it would start to add up, but it would still only be about 2MB for basically every block in current Minecraft, which includes far more block textures than you'd need with the current set of blocks supported. Considering that the CX has 64MB RAM and the OS runs on older models with 32MB, there's at least 32MB free (maybe badly fragmented), so that could actually work quite well (but slow down startup time significantly). I added it in the poll above. Also, hi.  I normally don't tread outside of 83+/84+ threads, but this is the one thread that I make an exception for and keep track of because your work on this is awesome. Thanks, what an houor  Out of curiosity because I don't have an Nspire and couldn't see the statistics anywhere in recent posts, what's the performance of this like relative to the draw distance? If you mean draw distance as in how many chunks far you can see, then I'd say it's about 15fps with 3 chunks (or however many blocks are in one +/1) rendering distance(overclocked to 198MHz). That entirely depends on how many triangles are visible. If you have a flat area, it's not much slower, but with hills it slows down quite a lot. For viewing distance I compute the distance to each chunk with sqrt, so it's not a cubic area, more like a sphere. Anyway, I made a few "benchmarks" with nspire_emu (fps counter makes crafti instable on real HW, which is also quite a bit slower):  | Normal distance, 28 fps |  | Normal + 1, 22 fps |  | Normal + 2, 17 fps |  | Normal + 5, 10 fps |  | Normal - 1, 36 fps |  | Normal - 2, 57 fps |  | Looking up at Normal + 5, 41 fps |
And yeah, I should probably make a video. GIFs are so damn ugly with just 256 colors but on the other hand it's quite annoying to record with a camcorder and play simultaneously.
482
« on: April 28, 2014, 12:18:29 pm »
Is the older kernel on this page?: http://tiplanet.org/nspire-linux-builds/ Yup, it's the "older kernel" Oh, one last question, how do i upvote/add reputation (to you)? If you can't see the red and green voting buttons on the left below the post rating, I guess you need to be at least LV2 or 3.
483
« on: April 28, 2014, 11:24:19 am »
Exactly. But the newer devicetree based kernel doesn't support USB at all, so you have to use the older kernel.
And append "rootdelay=5", as USB seems to be really slow on the nspire.
484
« on: April 28, 2014, 11:13:42 am »
Jup, I would essentially have to do:
for(int x = x_start; x <= x_end; ++x)
{
COLOR c = texture->bitmap[u + v*texture->width];
RGB rgb = fromCOLOR(c);
r *= light;
g *= light;
b *= light;
c = fromRGB(rgb);
screen[x + y*width] = c;
}For each horizontal line of every triangle visible. Maybe it's possible to premultiply the textures, but for 4 different levels of light that's already 2MB for a 512px texture. I don't know, maybe in a later version.
485
« on: April 28, 2014, 11:04:31 am »
No, you can boot from your flash drive directly.
486
« on: April 27, 2014, 06:23:13 pm »
Unlikely, that would require three additional multiplications per pixel. Day/night should be possible, though.
487
« on: April 27, 2014, 05:13:09 pm »
I won't publish v0.8.1 yet, as I still have to implent rotation of normal blocks, which requires refactoring a lot.
So, upside-down stairs? 
Maybe. Stairs aren't implemented yet, but that shouldn't be much work. I was referring to furnaces, crafting tables, bookshelves and pumpkins, actually. Stairs are "special blocks" as they don't consist of 6 axis-aligned quads with coords aligned to BLOCK_SIZE which is necessary for optimizations.
Wait...what do you mean by rotation then? Will the firery side of the furnace face you when you place, or is it something different?
Exactly that! The torches do that already (dependent on the side of the block you place it on).
488
« on: April 27, 2014, 03:25:24 pm »
I won't publish v0.8.1 yet, as I still have to implent rotation of normal blocks, which requires refactoring a lot.
So, upside-down stairs?
Maybe. Stairs aren't implemented yet, but that shouldn't be much work. I was referring to furnaces, crafting tables, bookshelves and pumpkins, actually. Stairs are "special blocks" as they don't consist of 6 axis-aligned quads with coords aligned to BLOCK_SIZE which is necessary for optimizations.
489
« on: April 27, 2014, 03:15:53 pm »
You can't. X11 doesn't fit into RAM three times (compressed with xz & uncompressed in ext4 filesystem & loaded as executable).
490
« on: April 27, 2014, 12:37:08 pm »
No, the busybox initrd isn't intended to be used as a "normal" initrd, instead of mounting external storage and switching "/" it drops you into a shell.
It should be possible to "mount --bind" the /dev, /sys, /proc and /var/run trees and chroot, though.
491
« on: April 27, 2014, 12:34:46 pm »
I voted for the inventory because I thought it would not take ages to code (unlike mobs, water and lava or redstone) After the necessary refactoring, water, lava and redstone should be very easy. Inventory would mean creating more textures and a whole new API. Meanwhile I fixed the GUI issues with external textures and rotation beyond your neck's capabilities. I won't publish v0.8.1 yet, as I still have to implent rotation of normal blocks, which requires refactoring a lot.
492
« on: April 26, 2014, 06:25:10 pm »
So it seems like the DEFAULT_N_TOKENS HAS to be at least 100....and, the documentation says mathomatic can run on a few mb's of RAM, so I shouldn't have to hack it down lower. Than you need to log what it dynamically allocates, either using gdb or a puts in malloc. If the allocations aren't that much (<5MB each), something else is wrong.
493
« on: April 26, 2014, 03:58:24 pm »
n_tokens? Try to set DEFAULT_N_TOKENS even lower, 10 maybe. The emulator worked fine until I restarted it. Did you save the flash? And I can't find the malloc function. "system" folder in where? In your ndless-sdk
494
« on: April 26, 2014, 11:59:49 am »
What do I want to do with exceptions in C? I don't know, but the makefile that came with mathomatic apparently had it in. Remove it! It doesn't make sense and exceptions will crash the calculator. Debug it: I can't. The emulator requires boot1 and boot2 and polydumper only dumps my boot1 for some reason, which I can't figure out. You can get a boot2 from tiplanet.org and from a OS image (.tcc or .tnc) if you rename it to .zip. nspire-gcc -Og -g -Wall -Wshadow -Wno-char-subscripts -Wno-unused-variable -marm -mlong-calls -fno-exceptions -DLIBRARY -DVERSION=\"`cat ../VERSION`\" -DSILENT=1 -DSECURE -DHANDHELD -c -o lib.o lib.c
cc1.exe: error: argument to '-O' should be a non-negative integer
make: *** [lib.o] Error 1
-Og throws the error I expected it too...where am I wrong here? Hmm, maybe your compiler doesn't support "-Og". "-O0 -g" should work as well, and also set "-g --debug" as flags for nspire-ld-bflt. Oh, and if I compile with arm-none-eabi-gcc, the calc freezes on the document screen right when I click on mathomaticndless.tns. I'm curious: why then and not after it loads the console? Some flags for gcc are missing, in particular "-fpic" so the code will crash after being loaded.
495
« on: April 26, 2014, 07:35:30 am »
Compile everything with "-Og -g" instead of "-O3", "-fno-execptions" instead of "-fexceptions" (What do you want to do with exceptions in C?)
and debug it. If you can, set a breakpoint at malloc or a puts call and find out what it's allocating.
Pages: 1 ... 31 32 [33] 34 35 ... 83
|
Show Posts