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 ... 24 25 [26] 27 28 ... 83
376
« on: July 07, 2014, 06:46:58 am »
I installed linux on my TI-Nspire CX CAS and it all works fine, except for the USB, I used the files here: http://tiplanet.org/nspire-linux-builds/ and I have a powered usb hub connected to my calc, and TI OS gives me the error message about an error with the connected device. lsusb shows nothing, and dmesg doesn't show anything useful. Any help? USB isn't really working in the DTB builds. It should work if you use the "Older kernel" without DTB. I just noticed on the wiki: It says "unknown" for the 84+ Link Port. I'm not saying I disagree with the following "do we need this" but I do want to point out that it just hooks into a few I/O pins on the CPU. It should be relatively easy to add support for it. The GPIO driver is also just setting and clearing some bits, but still >200 lines. Also, which subsystem should it use?
377
« on: July 07, 2014, 06:23:32 am »
Oh god, what did I do  and starting a pissing contest about which lib is better or not and doing so in someone else's lib thread. Yeah, I didn't expect that. I find it legitimate to be angry when people keep bashing my work and saying without any stats to prove it "yes my lib is faster than his lib". You asked me on IRC TWICE how you could optimize it further, I answered you and you ignored it, except for the "unsigned int" as x/y part. I even provided a nice list of suggestions but you ignored it again. If you don't want to implement it, don't say that your lib is faster. Not using "-Ofast" or at least "-O2" is just ignorant. And I wouldn't call a simple "And btw, it's faster than n2dlib  " bashing. Moreover, I keep proving my lib is not slow, but people keep ignoring me Which "people"? and seeing it as the slowest thing of the universe, at the point that they'll take any other lib instead of it. Your lib isn't slow in the meaning of "too slow". I never meant that. I just implied it could be much faster. Of course, if someone does test and proves by a + b that Vogtinator's lib is faster than mine at an identical task, then no problem. But just stating it with no numbers of any kind is insulting. Well, I don't need any benchmarks to compare multiple comparisions, branches and additions to a single increment. You even have a "performance-bug" in your code I already pointed out multiple times. (BTW: The ARM926EJ-S has a hardware multiplier. "mla" should be faster than "x + y<<8 + y<<6", but generally the compiler knows better, so "y*320" is always the best choice, combined with "-ffast-math") But if you want some, I'll make a benchmark for both libs. I guess rendering the same 32x32 tile from the center of a 128x128 tilemap onto the screen (to fill it completely) would do? If you don't trust me, you can make your own benchmark if you want to. Well that answers the "speed problem", but not the "efficiency" one because to convert the tab into a struct, well there is a need for a function to convert the tab into a struct -.- No reason to do anything like that, it's directly binary-compatible struct Texture {
uint16_t width;
uint16_t height;
uint16_t transparent_color;
uint16_t bitmap[];
} __attribute__((packed));
could work. Untested. or blaming it for nKaruga slowdowns on CX models (even though we all saw what happened with the transition from 84+SE to 84+CSE). That's not his fault, that's the hardware and it will be the exact same with nGL (may be a little bit faster as nGL doesn't invert each sprite, but rather the entire screen once before it's drawn). think it might be a better idea to use a different texture for the selected block since I tend to get confused with actual glass windows and stuff. Would a square with nothing except an outline that slowly flashes between black and white be better? Yay, on-topic again! Seems like I should use my graphics tablet again. A gif of a cute cat to calm down  
378
« on: July 06, 2014, 04:08:00 pm »
Jup, I wanted to nGL to be as flexible as possible, but without neglecting performance.
I actually thought about rendering the block list to a TEXTURE and letting it "fly in" from up front. I could also render the inventory/quick-select to a ribbon in circle shape (forgot the word) and rotate it so that the currently selected slot points towards the cam (or in a \_/ shape, viewed from above)
The opposite direction is possible as well, e.g. mirrors, portals, side-by-side view - but I don't know how to integrate it into crafti easily.
379
« on: July 06, 2014, 02:35:56 pm »
- Use a Texture struct rather than a unsigned short* for better readability.
Well, two of us come from Axe and care less about readability than about speed (even though it seems like we are not Nspire pros  ) or efficiency.
It should compile to the same code. If not, it could be faster due to alignment if you use a "flexible array member" ( StackOverflow question)
380
« on: July 06, 2014, 01:58:34 pm »
Okay so stop saying texturetools is faster than n2DLib : I just looked at your drawTexture routine, it's exactly the same as n2DLib's drawSprite It isn't (probably a typo, but drawTexture = drawSpritePart). I know, I probably sound like an asshole now (  ), but I already told you how you could optimize it: - Compile flags! With -Os gcc won't inline most functions etc.
- Multiple unnecessary checks, e.g. "x < 320 && y < 240"
- Unnecessary calculations per pixel, although you could do "c = ~c" once for each sprite
- getPixel and setPixel are unnecessary
- Too many branches. You should now that branches are the slowest thing ever on the nspire.
- Const correctness for pointer variables, e.g.
void drawSpritePart(unsigned short *src, unsigned int _x, unsigned int _y, Rect* part).
Otherwise part can't be cached by the caller - Various micro-optimizations gcc doesn't do somehow
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#L151GCC 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? 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] ; 0xffffffdeSome suggestions: - Use a Texture struct rather than a unsigned short* for better readability.
- drawPolygon shouldn't use a va_list but rather the pointsList directly, for flexibility and performance
But now it's getting rather off-topic... Edit: I didn't downvote you. I really like discussions both sides benefit from.
381
« on: July 06, 2014, 10:11:35 am »
Well, it only does crafti-relevant parts, so no 2d primitives, just texture operations, but the header files should be enough documentation: texturetools.hfont.hSmall example: #include <libndls.h>
#include "texturetools.h"
#include "font.h"
int main()
{
TEXTURE *screen = newTexture(SCREEN_WIDTH, SCREEN_HEIGHT);
nglInit();
nglSetBuffer(screen->bitmap);
while(!isKeyPressed(KEY_NSPIRE_ESC))
{
//Draw
glColor3f(0, 0, 0);
glClear(GL_COLOR_BUFFER_BIT);
drawString("Hi!\nThis is a small test!", 0xFFFF, *screen, 0, 0);
nglDisplay();
}
nglUninit();
deleteTexture(screen);
}
Edit: Forgot to #include <libndls.h>
382
« on: July 06, 2014, 08:58:30 am »
nGL renders only triangles, so is much more flexible in drawing textures at an arbitrary scale, rotation, translation etc., but that comes at the cost of: - Clipping
- Culling
- Z-Buffer
- Interpolation along X and Y-Axis (With textures: 3 divisions per scanline, without: 1)
which wouldn't be necessary for simple 2D stuff. That's also the reason I wrote a basically seperate lib "texturetools.cpp" to do 2d transformations (basically blitting, scaling, font etc.) on TEXTUREs. And yes, it's faster than n2dlib
383
« on: July 05, 2014, 03:48:01 pm »
It's purpose is to show you which block you're looking at currently. I'm very bad at drawing, but good at avoiding work and thus reusing other's
384
« on: July 05, 2014, 03:32:16 pm »
Small little teaser  : 
385
« on: July 03, 2014, 11:30:07 am »
Without your changes nobody can help you..
386
« on: July 03, 2014, 10:27:17 am »
However, I noticed, you're using nspire-ld for linking, which outputs ELF files and the attached binary is a bFLT file 
I'm using an old commit of your Ndless fork.
In your README.md is written: Use Fabian Vogt's fork of Ndless, commit ac7576f9cc2609789178270d86778a8e45b64464.which is the most recent commit. Do you think I should use Zehn by concatenating to the resources-loader? Exceptions will make your life much easier, and it will be a little bit faster (without -fPIE and -fPIC) There are two downsides though: Startup time will be a bit slower, the file would have to be loaded twice if .bss isn't included and debugging is only supported if you use Zehn without wrapper. Of course you can simply elf2flt the generated .elf file, and you have both Zehn and bFLT  BTW: You can safely delete and delete[] nullptrs, so every if(ptr) delete ptr; is redundant. And can you add memory.h? It should just #include string.h.
While you read this, it's already done Edit: Some suggestions: void fillScreen(unsigned char c) {
for (int i = 0; i < SCREEN_WIDTH; i++) {
for (int j = 0; j < SCREEN_WIDTH; j++) {
setPixel(c, i, j);
}
}
}
void fillScreen(unsigned char r, unsigned char g, unsigned char b) {
for (int i = 0; i < SCREEN_WIDTH; i++) {
for (int j = 0; j < SCREEN_WIDTH; j++) {
setPixel(r, g, b, i, j);
}
}
}
what about std::fill with custom pattern? void setPixel(unsigned char c, int x, int y) {
// On color models, each pixel is represented in 16-bit high color
// On classic models, each pixel is 4 bits grayscale, 0 is black and 15 is white
if (0 <= x && x < SCREEN_WIDTH && 0 <= y && y < SCREEN_HEIGHT) {
int pos = y * SCREEN_WIDTH + x;Simple trick to increase performance sigificantly: "unsigned int x, unsigned int y" obsoletes the comparision "0 <= x". bool init() {
buf[0] = new unsigned char[SCREEN_BYTES_SIZE];
buf[1] = origBuf;
if (buf[0]) {
if (std::atexit(deinit)) {
deinit();
return false;
} else {
atexitCalled = true;
return true;
}
} else {
return false;
}
}Ever heard of global variables? (std::vector could work, too)
387
« on: July 03, 2014, 05:52:12 am »
Looks good! How's the speed like now? I can't test it myself until I'm at home.. However, I noticed, you're using nspire-ld for linking, which outputs ELF files and the attached binary is a bFLT file
388
« on: June 30, 2014, 05:12:21 pm »
I just tried it on my CX CAS 3.1, the program doesn't crash for me and it takes ~6 seconds = ~167 fps. I don't know how to interpret it, I don't understand giving a mere 6 seconds at 132 MHz as well as 262 MHz, vs 12.58 seconds at 132 MHz and a bit more than 6 seconds at 262 MHz previously Edit: Could you post a program that writes 1000 times to something else than the screen? I don't think it could make a difference, but just in case..
389
« on: June 29, 2014, 07:12:06 am »
When I have more time again I'll try to do something.
A few bugs: Newline after "GDB connected" and disconncted is missing and you put the "Ndless not detected" message at the wrong place.
390
« on: June 29, 2014, 06:50:33 am »
Don't double post, the "edit" button has a meaning It's too hard to me to rewrite the asm code.I even don't know its meaning.Could you help me? I literally commented every instruction.. Except for some basic blocks. BTW: You can replace the "unaligned read at r9" by a simple "ldrb r9, [r9]". But you definitely need to understand it well enough to make such a rewrite. When i delete asm code in interrupt.c it has some problem,but it doesn't reset again. Which asm code in interrupt.c?
Pages: 1 ... 24 25 [26] 27 28 ... 83
|
Show Posts