Show Posts

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 ... 23 24 [25] 26 27 ... 83
361
TI-Nspire / Re: nGL - a fast (enough) 3D engine for the nspire
« on: July 09, 2014, 05:45:35 pm »
What I meant is since torches invert the signal, you need two of them to make a repeater, and then it's a two ticks repeater.
Oh, now I realized what you meant, I should really go to bed now  ._.
In that case (a torch-based repeater) the delay could be as bad as 4 ticks + chunk timing differences

362
TI-Nspire / Re: nGL - a fast (enough) 3D engine for the nspire
« on: July 09, 2014, 05:37:58 pm »
Quote
Actually repeaters still have two uses: delayers and diodes. They let you delay by one tick while torches need two ticks (since you need to re-invert the signal).
Looks like I haven't played minecraft in a while.. Added to the TODO list, but below everything else as not really necessary.
Redstone torches don't need two ticks: If the redstone wire connected to the torch is in the same chunk, it changes state every tick. (Not entirely true, it also depends on position and orientation of torch and redstone, like water which behaves a bit weird at chunk borders).
This could be an issue for repeaters, as it may be that the receiving redstone (at the repeater output) gets updated before the receiver changed state and thus having a two-tick delay. Ticks aren't even synchronous for Chunks, each chunk has its own timer, so it's distributed more evenly to prevent lag spikes. I could implement it more "reliable", but only with a heavy impact on overall performance and complexity.

363
TI-Nspire / Re: nGL - a fast (enough) 3D engine for the nspire
« on: July 09, 2014, 05:20:38 pm »
Quote
Will pistons, comparators, and repeaters and the like be implemented?
Comparators have nothing to compare and repeaters nothing to repeat: Redstone in crafti is infinite!
I was actually planning to implement pistons in v1.1 but thought the last release was so long ago that I should release something.
It will come in v1.2 (or v1.1.1 maybe), probably together with stairs and maybe mobs.

Quote
Also that looks great  does it still work on GS calcs which use the 3.1 version of Ndless, since you now use another executable format ?
It should even run on some versions < 3.1, I'm not using much except fopen etc. at all.

364
TI-Nspire / Re: nGL - a fast (enough) 3D engine for the nspire
« on: July 09, 2014, 04:06:56 pm »
If you use most standard C/POSIX features like sprintf, fopen and opendir the MINIMUM executable size is 52K on my fork, which is more than the current ndless_resources_3.6.tns  :o  But still less than a fullscreen image :P

Could we keep this slowly getting ridiculous and annoying discussion about n2dlib vs nGL and Matrefeytontias vs everyone out of here and/or just FORGET it?

365
TI-Nspire / Re: nGL - a fast (enough) 3D engine for the nspire
« on: July 09, 2014, 03:58:04 pm »
And there's still more to optimize. Partial loop unrolling as 2x16bit access is slower than 1x32bit for example.

To give you an example of a almost fully optimized function, I optimized drawTexture some more: https://github.com/Vogtinator/crafti/blob/master/texturetools.cpp#L151
GCC does some partial unrolling, but doesn't transform 2 16bit accesses (ldrh/strh) to 32bit access(ldr/str), although -Ofast should do something, should I report a bug?
Code: [Select]
    8e28:   e15392b4    ldrh   r9, [r3, #-36]   ; 0xffffffdc
    8e2c:   e14292b4    strh   r9, [r2, #-36]   ; 0xffffffdc
    8e30:   e15392b2    ldrh   r9, [r3, #-34]   ; 0xffffffde
    8e34:   e14292b2    strh   r9, [r2, #-34]   ; 0xffffffde

There are actually two reasons why a compiler cannot use 32bit memory move instructions here.

1:
Code: [Select]
COLOR *dest_ptr = dest.bitmap + dest_x + dest_y * dest.width, *src_ptr = src.bitmap + src_x + src_y * src.width;dest_ptr might be src_ptr + 1 ( *src_ptr is not const ) so moving two texels for this case will produce different results.

2:
It is not guaranteed that src_ptr and dest_ptr are each aligned to 4 byte which is required if you want to move 4 byte at a time on ARM.

To 1: I tried various GCC options to force such an optimization (but actually overlooked the missing const, thanks!)
2: Various GCC options + __builtin_assume_aligned
and it just doesn't want to optimize it -.-

Quote
First, sorry for being angry like this. I know it's ridiculous and shit, but I just had enough of seeing people implying the lib was supposedly slow. (and Vogtinator I never meant you, I know aeTIos kept saying it some time ago although he stopped now ; or maybe I'm just being too proud or paranoid, don't know which).
Well, then I wonder why you posted here.. To tell everybody my lib was slow as well/as fast as yours?
That "by the way, it's faster than n2DLib" just sitting here without any further development really made me upset.
From my POV you ignored my hints and I just had to write it, sorry.

366
TI-Nspire / Re: nGL - a fast (enough) 3D engine for the nspire
« on: July 09, 2014, 03:50:52 pm »
I'm not creative enough to write some kind of intro, so here you go: Crafti v1.1 ;D
New features:
  • Redstone!
  • New executable file format Zehn
  • Take a screenshot ("/documents/ndless/screenshot_NR.ppm.tns") with Ctrl+. in-game
  • Change your FOV! The closer your near plane, the bigger your FOV (but also less fps)
  • Messages appear if the world has been loaded, saved, a screenshot taken or settings applied
Bugs fixed:
  • Bounding box of wheat
  • Embarrassing rounding error fixed: The weird line at the right screen edge is now gone!
  • Apparently confusing indicator texture changed to something animated
  • Better performance due to cache preloading, more GCC optimizations and Zehn
  • No crashes due to exhausted RAM: Exceptions are caught and terminate the app instead of rebooting!
Known issues:
  • You can fall through pressure plates
  • You can get stuck in a closed door
Redstone tutorial:
Redstone in crafti works a bit different than in minecraft, redstone wire doesn't need to be on a block, it's a block by itself and can be placed on everything including air and redstone torches!
Each block has two states: Powering or not powering. Examples for powering blocks are turned-on redstone torches, turned-on switches, pressure plates you're standing on and powered redstone wire. Redstone torches are on by default and turn off if any block surrounding the block the torch has been placed on is powering (ignoring the torch itself, of course). Redstone lamps glow if any block surrounding them is powering. Doors open if any adjacent block is powering or being powered.

Some screenshots to give you a better idea of how it works and looks like:

Switch turning redstone torch off and on:


Pressure plate turning on a redstone lamp:

It doesn't turn off directly after stepping off of the plate, there's a delay of 5 ticks, so doors stay open a bit longer and don't close directly in front of you.

Wire controling a floating lamp:


And the most basic redstone logic gate: The inverter!


Due to redstone wire being a block a clock is very simple:

The redstone torch controls the wire underneath, which is connected to the wire which controls the torch. First I thought it's a bug but actually it's rather useful!

Of course doors work as expected:

If you want to see how pressure plates and doors play together, you'll have to try that yourself :P

Have fun!

367
TI-Nspire / Re: nGL - a fast (enough) 3D engine for the nspire
« on: July 09, 2014, 02:50:37 pm »
<off-topic again sorry, but got to clear that up>

Okay so I finally have a computer again, so I worked on n2DLib after several days when I couldn't. So I tried to implement your suggestions as good as I could.
Looks better, but still a lot to improve! (any branch per pixel, for instance if(has_color) definitely needs to go!)

Quote
First, sorry for being angry like this. I know it's ridiculous and shit, but I just had enough of seeing people implying the lib was supposedly slow. (and Vogtinator I never meant you, I know aeTIos kept saying it some time ago although he stopped now ; or maybe I'm just being too proud or paranoid, don't know which).
Well, then I wonder why you posted here.. To tell everybody my lib was slow as well/as fast as yours?

Quote
Anyway, well, it's a lib, so compile flags are up to the user.
Yeah, but then you should use the correct flags for your example, it's an example after all..

Quote
DJ : I didn't want to start a war about what lib was better, I was just asking please stop assuming my lib is slow without even trying it or wondering if that's not your code's fault x.x I remember some days ago on IRC, Streetwalrus was saying something like "tetris is slow, it's n2DLib's fault" and was serious about it, and of course it turned out the problem was his own code. The fact itself isn't really important, it's just the way of thinking that's annoying. But let's forget that and pretend it never happened.

Vogtinator : for your optimizations, I do remember me asking you some, but I don't know, maybe I was working on something else at that moment so I forgot afterwards <_< I did my best at implementing them this time, it should be visible in github's history.

Although I find it a good idea, I can't afford inverting the buffer only when updateScreen-ing depending on the screen model, because maybe one day someone will not want to erase the buffer each frame and that will give weird results.
That's the reason nGL allocates a third buffer on monochrome calcs (yup, one on CX and three on non-CXs)!
320*240*2 = ~155KB, that's almost nothing.

Quote
So I guess that's it, sorry for the off-topic, sorry for being upset, sorry for saying stupid shit, things like that.

Back on-topic, when testing the last version on an emulated TI-Nspire CX CAS with Ndless 3.1 r914, I noticed you couldn't swim in water nor lava, is that intended ?
No, definitely not! You can't swin in lava and water needs to be at least two blocks deep to swin in.
I just tested and it works for me :-/

Edit: Is it permitted to double-post to seperate a release announcement from the rest?

368
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: July 08, 2014, 04:33:45 pm »
Howto: Extract tar files onto a ext4 partition:
Code: [Select]
sudo -i
mkfs.ext4 /dev/sdbX
mount /dev/sdbX /mnt
tar -xvf xconfig_latest.tar.xz -C /mnt
umount /mnt
exit

369
Other / Re: Having fun with a Samsung digital camera
« on: July 08, 2014, 01:26:38 pm »
Nice, I was always wondering if it was easy to hack digital cameras :thumbsup:
Quote
in case someone...makes it less usable...
Like.. yourself? :P
* ElementCoder runs
j/k
I can actually tell a story about something like that. My grandpa owns a camcorder (really cheap crap) and I tried to change some settings as the pictures and videos were really awful. So I tried to change the resolution and other properties, which is called "Bildformat" in German.
Now in the main menu there was an option called "Format". I assumed it's the "Bildformat" and clicked on it. And no, it wasn't. SD card empty, photos of a full year lost, without any backups  >:(
Aww that really sucks :( They really should make those options hard to access to avoid these kind of accidents.
Hmmm shouldn't there be a confirmation prompt ? <_<
There was. A single window with a single button in the center, called "Ja"/"Yes". Nothing else.

Quote
This happened to me too once, but luckily I was able to restore everything from the formatted SD card using a program to undelete files.
I haven't had the time to do that and it was only his secondary camera anyway, it was so bad he barely used it. Still, there were quite a few pictures on there. And IIRC formatting took so long that after clicking on "Ja" I first thought it crashed or freezed. I wasn't quick enough to remove the battery, so I'd assume it didn't only format but rather clear the entire card, but I can't tell for sure.

370
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: July 08, 2014, 10:53:15 am »
I'm not 100% sure but you should omit the '"'s.

371
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: July 08, 2014, 09:28:45 am »
Did you add the correct dev file as "root=/dev/sdX" in the loader script?

372
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: July 08, 2014, 08:09:43 am »
Try to boot an initrd and mount the usb manually, does it work?

373
Other / Re: Having fun with a Samsung digital camera
« on: July 07, 2014, 04:51:46 pm »
Quote
in case someone...makes it less usable...
Like.. yourself? :P
* ElementCoder runs
j/k
I can actually tell a story about something like that. My grandpa owns a camcorder (really cheap crap) and I tried to change some settings as the pictures and videos were really awful. So I tried to change the resolution and other properties, which is called "Bildformat" in German.
Now in the main menu there was an option called "Format". I assumed it's the "Bildformat" and clicked on it. And no, it wasn't. SD card empty, photos of a full year lost, without any backups  >:(

Quote
now publish a screenshot with Ricky on it. :p (nice redirection though, nice one)
Give me the URL and I'll do it!

Whoa that's a nice hack.
Reminds me of how the Gamecube was first hacked. Basically there was that online game that downloaded updates from the server. Binary executable updates that is. And guess what : there was no check. :P  So people just set up a custom DNS and server to upload binaries to the console.

I hope you can do something interesting with this.
I've got a windows VM somewhere so I can probably get a firmware dump (and the source code, maybe) which may be modifyable. Shell access would be nice  ;D

374
Other / Having fun with a Samsung digital camera
« on: July 07, 2014, 03:47:30 pm »
My old (well, 4 years old) camera doesn't want to open the shutter anymore, so it was time to get a new one, primarily for the school trip to croatia in two weeks  ;D
It had to be cheap, in case someone steals or somehow makes it less usable, you know  <_<
Most cams in that price range were awful, REALLY awful, but the samsung wb350f was nice to control and looked a bit less plasticky than the other ones. </advertisement>
It has a whole lot of totally useless features, like an NFC tag, Wi-Fi connection to upload pictures and movies to picasa, facebook, dropbox, youtube, send it per email, a baby monitor (not kidding!), remote control using a smartphone (I don't have one, just a normal mobile phone) and the list goes on and on.
But to upload to dropbox, it has to register a oauth token and such it opens a webbrowser to a dropbox login page with some samsung customizations. You can probably guess what comes next: Set up a DNS server to redirect (CNAME) www.dropbox.com to a custom server with ssl certificate and redirect everything to http://google.com. Success!


The browser doesn't seem to support CSS or anything like that, but the font rendering is quite good ::)
I would love to play around with this some more, but without windows I can't do firmware updates, use the samsung software etc. >:(
I found a directory "java" on the microsd card, so the browser (forgot the name) may be java (ME?) itself. Also a previous model is a bit more open in a hack-friendly way and runs enlightenment, so probably linux-based?
Let's see what this thing can do!

375
TI-Nspire / Re: Calling all Linux Kernel developers!
« on: July 07, 2014, 12:27:25 pm »
Quote
Sweet, thanks! Any idea when USB will be supported in the newer builds?
Probably never, I don't know why it doesn't work if I simply tell the DTB the EHCI address and IRQ. Maybe some initialization differences.

Quote
Also, what is the difference between the defconfig and expanded builds for the old kernel?
It's simple: The defconfig has only those options activated which are required for booting. Just use the expanded kernel if you want to use it, it has most required drivers included.

Quote
I wonder if it's possible to have a small, light-weight GUI application with this, like a small menu based file browser. That'd up the functionality by a lot.
Depends which files you want to browse. I reverse-engineerd the highest level of the filesystem (reliance) and have a basic fuse driver ready, but the lower level (flashfx) isn't implemented yet.

Pages: 1 ... 23 24 [25] 26 27 ... 83