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 - hoffa
Pages: 1 ... 9 10 [11] 12 13 ... 21
151
« on: March 25, 2012, 09:56:16 am »
Booyakasha!
0.1.4's up. It should actually be 0.1.3b or 0.1.3.0.0.0.1 as it contains very little code changes, but hey, who wants to stay in 0.1.* forever? I'll probably jump to 0.2.0 once I get the mouse to work, just for shits'n'giggles.
Anyway, basically this version goes hand in hand with the new how-to guide. First of all I hid that whole NSP_COLOR_LCD thing from the user as it complicates the build process and whatnot. Then I added a very easily adaptable Makefile.sample file to the final archive which simplifies the build a lot (only a make cx/tc is needed to build now, no more cryptic commands). Also I added a primitive README file to the said archive; it doesn't really help anything at all (who reads README's anyway?) but it makes it look more serious. Then I did some general housekeeping to the code and removed some mouse-related test stuff clogging up the event loop. Oh and as I mentioned a few sentences earlier, I updated the how-to guide.
There won't be any updates for at least a few days as this version has been clinically proven through rigorous scientific experiments to be a "stable beta".
Have fun.
EDIT: Added images of the available fonts.
152
« on: March 24, 2012, 01:37:29 pm »
It wasn't even -Os, I at first used no optimization (i.e. -O0) for stability purposes and then forgot about it.
153
« on: March 24, 2012, 01:07:01 pm »
Faster as in it draws faster. As I mentioned a few posts earlier, it improved drawing speeds by about 110% (i.e. over twice as fast). EDIT: here
154
« on: March 24, 2012, 12:48:37 pm »
Finished writing the how-to guide. Enjoy.  Also rolled out 0.1.3, only change being the -O3 switch in the Makefile which gave a huge performance boost.
155
« on: March 21, 2012, 10:08:21 am »
I've tried porting some very small SDL programs and it works well. Haven't tried porting anything bigger yet though.
As far as the libs are concerned, most of the libs there seem portable. SDL_image for instance certainly is, and it's on my todo list.
156
« on: March 20, 2012, 05:11:49 pm »
Oh wow what a mistake, so it was the 16x16 after all. No wonder the results seemed too great to be true. Well seems like there's not much difference with the 16x16 (although maybe 1000 blits is too little), but in a 1000-blit run it seems to be about 50 ms faster on the CX with the 32x32 image. Thanks for the information. Once I get the more important stuff working (mouse for instance), I'll look into performance. EDIT:
Good news. I hadn't compiled with any GCC optimization yet and had forgot about it. Now I compiled SDL with -O3 (i.e. highest optimization level), and the size went from 383K to 241K. But most importantly, with the exact same 32x32 image on a 1000-blit run, it took 325 ms without optimization, and 155 ms with optimization. That's over twice as fast. I checked and rechecked, and it is indeed true. I tried with a 10000-blit run this time, one program compiled with no optimization and the other one with O3. Here are the results that fit the previous finding: (10000-blit run, 32x32 BMP image) Unoptimized: 3261 ms or 3067 blits/s (+0%) O3 optimized: 1555 ms or 6431 blits/s ( +110%)
157
« on: March 20, 2012, 04:40:39 pm »
1000 blits in 113 ms means 8850 blits/s for a 32x32 BMP image, while on the non-CX it was 2994 blits/s. If your figures and my calculations are correct, that's nearly three times faster than on the non-CX. Damn.  Is that correct or am I just missing something and failing at basic math? (EDIT: indeed I messed up, it was 16x16 not 32x32) EDIT: Could you (or anyone else for that matter) replace the image.bmp.tns, by the one attached (it's the 16x16 one)? Thanks a lot, you're doing a great favor.
158
« on: March 20, 2012, 03:20:52 pm »
0.1.2's out, it contains mostly just minor changes. One useful addition though is printf-like formatting for SDL_nDrawString (along with NSP_COL and NSP_ROW to easily align text).
For example, to draw "Hello 0xFFFF, 42, world!" in row 1 (starts from 0) column 5, you could do something like (just replace the values by variables of course, otherwise it's useless):
SDL_nDrawString(screen, font, NSP_COL(5), NSP_ROW(1), "Hello 0x%X, %d, %s!", 65535, 42, "world");
It also supports tabs and newline characters, and text wrapping.
I've looked at the mouse stuff, and I might be able to implement that for the next release. I'll also write a full how-to guide to (I reckon it's not very homely when I just dump the headers and static libs in a zip file) and a few example codes in the thread soon.
EDIT:
Could somebody check how fast sprites are blitted on the CX? Download the zip and copy both TNS files to the Examples folder on your TI-Nspire, then run sdl_test.tns. I'm not sure how well memcpy is optimized, but with some magic it might (it's a vague guess though) be faster on the CX than on the non-CX. Thanks a lot.
159
« on: March 18, 2012, 09:20:00 am »
Seems pretty good for a start. Performance hasn't really been my main thing yet though, as I have been dealing with more important stuff. In later versions I'll optimize whatever possible to squeeze all the juice out of the TI-Nspire. (memcpy I'm looking at you)
On a side note, I'm working on getting SDL_image to run, i.e. support for a lot of different image formats.
160
« on: March 17, 2012, 04:25:01 pm »
Image:  (16x16) 1000 blits in 114 ms: 8772 blits/second Image:  (32x32) 1000 blits in 334 ms: 2994 blits/second EDIT: Trying out alpha, just posting this here as it gives a nice-looking CRT effect (well, more or less): (don't mind the results, it's on an emulator)  Alpha doesn't work on palettized surfaces though (i.e. Touchpad/Clickpad models), although I could hack it a bit and add support for them. EDIT2: Here's the code I used for the benchmark test: http://pastebin.com/vvdpJq57
161
« on: March 17, 2012, 03:58:28 pm »
I did some benchmarking, and the performance seems rather good. Blitting 1000 times a 100x100 BMP image takes about 2.6 seconds. See for yourself:
162
« on: March 16, 2012, 11:37:39 am »
Just finished rewriting the thread, it's still missing a lot of things (how-to, screenshots, etc.) but it's a nice start. Also removed yesterday's 0.1.0, as it was missing the headers and still had the old clumsy SDL_NSP_* functions. So I quickly rolled out 0.1.1, that'll be the starting point. I haven't written any instructions yet, but those who know their way around SDL and static libraries can already start playing around with it. I also renamed the project to nSDL; I wasn't to fond of the n-prefix, but TI-Nspire SDL just seemed too massive, so nSDL it is then.
163
« on: March 15, 2012, 03:42:53 pm »
It's working very well, and the timer is very accurate! 
Good to hear, seems like the problem's only on the non-CX models then (the value increases at the speed of light). Once I finish studying I'll go and beat the crap out of that timer bug, do some housekeeping and release the beta (very probably tomorrow, unless I once again end up going to bed at around 1 AM). Thanks again. EDIT: I'll probably make some how-to thread for those new to SDL with instructions, links to tutorials and such things once something's ready. EDIT2: Just released TI-Nspire SDL 0.1.0.
164
« on: March 15, 2012, 03:14:14 pm »
Alrighty guys, I'm happy to announce the first beta version of SDL for the TI-Nspire will come out very soon. But before I can do that, I need someone to check one thing on their physical CX. It's everything but complicated; download the attachment, send it to your calculator and enjoy the nice fonts and just observe how the timer increases. It should output the number of milliseconds since SDL initialization, so it should increase at a rate of 1000 a second. Press any key to update that value. If it increases way too fast, just tell me. That's all I need you to do, it should take just a few seconds. Thank you a lot for whoever helps me; the faster I get the info the faster I can release SDL. I've made quite a few changes since last update. I changed to a much faster, more flexible and cleaner font system, updated the timer stuff, fixed some issues and whatnot.
165
« on: March 14, 2012, 04:36:23 pm »
I tried setting BASE+0x80 to 0xA later but it didn't do anything. Also I checked the ARM Linux code to see how it dealt with the same timer, and it set the Value register; tried doing the same, that's why it's there. Actually I checked the code I posted in PM, and it did work to a certain extent, but now I remember the issue was with setting the Load register. It's as if it took some time before the timer became aware of the new value, and consequently measuring intervals became a mess. Well now I just decided not to play with the Load register at all. Here's the code that works for any future wanderer that might end up in this thread:
#include <os.h>
int main(void) {
volatile unsigned *value = (unsigned *)0x900C0004;
volatile unsigned *control = (unsigned *)0x900C0008;
int i;
*(volatile unsigned *)0x900B0018 &= ~(1 << 11);
*(volatile unsigned *)0x900C0080 = 0xA;
*control = 0b10100010;
unsigned start = *value;
for(i = 0; i < 10; ++i) {
printf("timer: %u\n", *value);
sleep(100);
}
printf("diff: %u\n", start - *value);
return 0;
}
Thanks again.
Pages: 1 ... 9 10 [11] 12 13 ... 21
|
Show Posts