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 ... 36 37 [38] 39 40 ... 83
556
« on: March 09, 2014, 05:33:45 pm »
The next version is ready! New features compared to v0.5: - Loading and saving (If you exit with ESC it's saved automatically) - File association (configure with ndless.cfg.tns) for worlds - Blocks can have a different texture on each side - More blocks: redstone ore, iron ore, gold ore, diamond ore, sponge, dark planks, bright planks, tnt, furnace, crafting table, bookshelf - A menu you can open with the menu key (8+2: Choose option 5: Select) - An "inventory" with all available blocks (period key) Animated screenshot of nspire_emu:  Disclaimer: It's a gif, so some colors look really awful. The menu transparency looks better than it does here. If you want to compare the speed of nspire_emu vs. hardware, open the menu on your calculator! A "saving bar" is unnecessary in my opinion (and difficult to implement as loading/saving isn't async). It enables the user to know that it is normal that nothing happens and to know how much times he has to wait. If it is difficult to know the time needed to save, you could just display on the screen "saving...".
It doesn't take a noticable amount of time to load and save. The delay you experienced was the call to refresh_osscr() which isn't really necessary, so I removed it. How? Exactly how I did it when textures are disabled? (color *= 0.8f)
Or two different texture packs?
Both versions would increase loading time (before you can see anything) as I either have to precalculate the textures or load another one.
Or should I seperate textures from the main executable which also makes "texture packs" possible?
Not like when textures were disabled but put a different luminosity for each side (the same for all tops, the same for all east-oriented faces etc.). But yes for color*=0.8f. Since the loading time is currently really short, I think the better solution is the precalculation.
But that would mean on a "wall"-like structure you couldn't see where you put a block. Checkerboard ((x + y + z) % 2 == 0) would make more sense, I think.
557
« on: March 09, 2014, 10:07:35 am »
The file association works! Could you add a loading bar when we quit the program when it saves the world? The next thing I do will be a nice menu. A "saving bar" is unnecessary in my opinion (and difficult to implement as loading/saving isn't async). Now, if I could suggest something: make the different same nature blocks distinguishable. How? Exactly how I did it when textures are disabled? (color *= 0.8f) Or two different texture packs? Both versions would increase loading time (before you can see anything) as I either have to precalculate the textures or load another one. Or should I seperate textures from the main executable which also makes "texture packs" possible?
558
« on: March 09, 2014, 09:59:55 am »
Just out of curiosity, if the CPU could run at a much higher speed, why didn't ARM set the speed higher? TI wanted to have a higher battery life time and little power consumption. Everything file that I have is 16MB or less, so flash memory performance shouldn't be too big of an issue when actually playing a game. The flash is incredibly slow. Really slow. The RAM speed can be compared to computer HDD speeds and the flash to a below average-speed DSL connection. At least that's what linux told me, but it feels like it's the sad truth 
559
« on: March 08, 2014, 08:20:02 pm »
I noticed this when I downloaded Crafti onto my calc and it ran a lot slower than it did in the picture. That's only because it's running in nspire_emu. On a real nspire there are some other things affecting speed, e.g.: - caches - RAM wait states/speed - Pipeline stalls - touchpad and keypad (I2C for the touchpad is slow) they aren't emulated accurately enough to behave just like the hardware but it depends on which software is being run. Especially crafti, which depends on memory speed mostly, is very much affected by this. Sorry if I was a bit ambiguous, but I was asking if overclocking would slow your calc down in the long term. If you can't notice any difference after overclocking, it's better for just a single reason: Saving battery charge! Higher speed means more power comsumption, basically. There's no other disadvantage to it. But DO NEVER, EVER increase your AHB frequency further than 66 MHz! You may corrupt some important data which cannot be restored afterwards and your calc could be bricked forever. The higher loading times you experienced could be some other clock (e.g. SDRAM, I don't know what clocks are connected to which peripheral in the nspire) still at a lower speed. If the RAM was fast enough to load a word in four CPU cycles, it may be ten now. Or you have a lot of files on your calculator which slows down file access a lot. If it takes very long to open the document browser (after bootup, not standby), backup the important files and format the partition using the maintenance menu.
560
« on: March 08, 2014, 05:56:55 pm »
WOW, 13GB is massive. Which log file was it?
On my servers systemd handles logging just fine. You can even set a nice size limit for the syslog.
And for other services which log into own files there's logrotate.
561
« on: March 08, 2014, 12:42:48 pm »
What are your settings for nover to play this? You don't need nover at all, in fact, it would make it even slower as crafti's performance is more dependant on memory speed than CPU frequency. As you would have to decrease the AHB freq., it also decreases SDRAM speed. I didn't measure anything as the fps timer doesn't work reliably yet. The use of the touchpad like a mouse is really a great idea!
The problem of the splitting into 16x16x16 pixels is that the variation of the length of view can have a factor of 2... Why not split into 8x8x8? It's easier to have those chunks only on one layer. As 8 blocks maximum height isn't enough, it would mean stacking chunks on top of each other. That complicates the terrain generation (currently two sine waves) and it would degrade performance a bit as more blocks are neighbors of other chunks, which means calculating the global block position, finding the corresponding chunk and calculating the local block position in the chunk for every block of the chunk's edges. Chunk loading is also horribly slow (light calculations, notifying the chunks around it, building the mesh) so it would be quite noticable when you're walking around. But I'll try it, I need to find the perfect size first before I implement saving. I can't wait to be able to save! :p Don't worry, I already started implementing it, only a matter of some weeks  I'll also try to improve terrain generation and create a nice menu and inventory/HUD. Should I go the creative-mode way or rather survival-mode? Edit: Implemented loading and saving. You can also make a file extension association in your ndless.cfg.tns (untested). Please tell me whether it works for you! The default filename is /documents/ndless/crafti.map.tns
562
« on: March 06, 2014, 05:34:46 pm »
It took a bit longer this time, I had to trace a really weird bug down to an overflow in the backface culling function  The first playable release of crafti!   Changes: - Fewer bugs
- Larger cubes
- Better controls:
8-4-6-2: Move
5: Jump
1-3: Change block (top left corner)
7: Put block down
9: Remove block
Touchpad: Look around like you are using a mouse - More blocks! Planks, coal ore, brick wall
- Faster! (A bit laggy, but playable)
- If no textures enabled, the color of a block is determined by calculating the average of its texture
Please tell me what you think!
563
« on: March 04, 2014, 02:44:31 pm »
The inner loop of nglDrawTexture is:
for(int x = x1; x <= x2; x += 1, ++z_buf, ++screen_buf)
{
if(__builtin_expect(*z_buf > z, true))
{
*z_buf = z;
#ifdef TEXTURE_SUPPORT
*screen_buf = texture->bitmap[u.floor() + v.floor()*texture->width];
#else
*screen_buf = low->c;
#endif
}
#ifdef TEXTURE_SUPPORT
u += du;
v += dv;
#endif
z += dz;
}
Another conditional branch per pixel would ruin the performance.
564
« on: March 04, 2014, 01:36:42 pm »
I'm splitting the world into chunks (16x16x16 blocks) which makes things much easier.
As I mentioned earlier, I cannot color textured triangles, as it would require 3 multiplications per pixel.
I could create a second texture and preprocess it, but that would either increase startup time, memory footprint or executable size.
The speed difference between textured blocks and untextured blocks is so insignificant, that a simple if(texture != nullptr) would slow things down more than simply enabling textures the whole time. I could, of course copy the function and split it into nglDrawTexturedTriangle and nglDrawTriangle, but that's code duplication.
What do you think?
565
« on: March 03, 2014, 08:13:23 pm »
It's carnival here in germany and therefore holidays  I got around to nGL and crafti and played around with the graphics pipeline to split projection and transformation. This fixes the division/near-zero error and therefore most artifacts but it got a lot slower as I cannot cache any vertices for projection as easily as before. 1 and 3 change the block type you'll put down (actually changing, adding isn't implemented yet). Moving around works exactly like before but now collision detection makes it impossible to move into blocks now  I haven't tested the current version on my calculator (it works in nspire_emu, ndless r914 without crashes) and I'll upload it when I confirmed that it doesn't only work on virtualized calculators.  TODO: -Looking around by touching the touchpad, not by clicking -Fix remaining bugs -Add blocks -GUI -Save and load world -Optimize! Edit: It works on my calc. The FPS counter doesn't like to be used simultaneously with the keypad, so I had to disable it for now. I also disabled Z_CLIPPING so triangles will be completely discarded if only partially visible. I appreciate any kind of feedback!
566
« on: March 03, 2014, 08:56:35 am »
E-Mail? I didn't get an E-Mail..
Anyhow, the new theme is like gnome3, looks good but is unusuable.
Usability should be the first goal of any design, not the look.
1. Borders: Left and right, black. Why? If I zoom out they stay the same size.
2. Size + Spacing: On my 1366*768 laptop screen I can barely read the title of the first post without scrolling and at the bottom I can't even see the last post.
3. Where are the new posts listed? I want a short overview what happend while I was away and not a huge list with the posts themselves.
4. Bad post layout: No newline for text after images, look at the news section
I hope I'm the only one who thinks the current theme is total crap compared to the old one.
I'm looking forward to be able to use the old ones again.
And a smaller issue (I'll report on ourl.ca/issue):
OmnomIRC isn't visible on the quick-reply preview page.
Sorry if I under-appreciate your work, I know how hard it is to satisfy everone, especially with a new design...
567
« on: February 28, 2014, 10:46:32 am »
I went through the code again and found a call to vprintf in my substitute to the irq-disabling printf...
I'll upload when I'm done with a better clipping algorithm and nicer perspective calculations.
Both should result in fewer artifacts and crashes, if they were related to drawing across the screen borders and thus overwriting some innocent memory which didn't seem to hurt the emulator.
568
« on: February 27, 2014, 05:02:25 pm »
You don't have to apologize  I'll try it on my calc tomorrow.
569
« on: February 27, 2014, 04:51:36 pm »
I'm testing on the emulator under the exact same conditions. My calc currently runs on OS 3.6 and switching just takes so long...
Could you try this version?
570
« on: February 27, 2014, 04:06:59 pm »
You can, under "Environment" in the drop down menu on the top right.
Pages: 1 ... 36 37 [38] 39 40 ... 83
|
Show Posts