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 - hoffa

Pages: 1 ... 13 14 [15] 16 17 ... 21
211
Calculator C / Linking static libraries on the TI-Nspire
« on: January 25, 2012, 05:17:38 pm »
I'm porting SDL for the TI-Nspire and ran into some issues while trying to link the resulting static library. I (or rather, the Makefile) first compiled all the SDL source files into objects:

nspire-gcc -Iinclude -nostdlib -lgcc -c in.c -o out.o

It all compiles well, and then I put those objects through ar and ranlib to create a nice libSDL.a. Now when I tried to link that library with some very basic code (just in order to test at least some function is recognized):

Code: [Select]
#include "SDL.h"

int main(void) {
SDL_Init(SDL_INIT_VIDEO);
return 0;
}
Using:

nspire-gcc test.c libSDL.a -Iinclude -lc -lgcc

GCC complains:

Code: [Select]
$ nspire-gcc test.c libSDL.a -Iinclude -lc -lgcc
C:\Users\Hoffa\AppData\Local\Temp\ccSJ5EA5.o: In function `exit':
sdl.c:(.text+0x220): undefined reference to `__crt0_savedsp'
sdl.c:(.text+0x224): undefined reference to `__crt0exit'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-exit.o): In function `exit':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\stdlib/../../../../../newlib-1.19.0/newlib/libc/stdlib/exit.c:65: undefined reference to `_exit'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-abort.o): In function `abort':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\stdlib/../../../../../newlib-1.19.0/newlib/libc/stdlib/abort.c:63: undefined reference to `_exit'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): In function `_kill_r':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\reent/../../../../../newlib-1.19.0/newlib/libc/reent/signalr.c:61: undefined reference to `_kill'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-signalr.o): In function `_getpid_r':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\reent/../../../../../newlib-1.19.0/newlib/libc/reent/signalr.c:96: undefined reference to `_getpid'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\reent/../../../../../newlib-1.19.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk'
collect2: ld returned 1 exit status
If I do not link it with libc/newlib (which would actually be better as far as I can see), it would complain about undefined references to memset(). (something warned about in the GCC man pages)
If any of you know how to deal with this issue, it would help me quite a lot; I could start testing some real code.

Edit:
This is the output when compiling without newlib (i.e., -nostdlib instead of -lc):

Code: [Select]
$ nspire-gcc test.c libSDL.a -Iinclude -nostdlib -lgcc
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/bin/ld.exe: warning: cannot find entry symbol _start; defaulting to 00008000
C:\Users\Hoffa\AppData\Local\Temp\ccqMjuGx.o: In function `exit':
sdl.c:(.text+0x220): undefined reference to `__crt0_savedsp'
sdl.c:(.text+0x224): undefined reference to `__crt0exit'
libSDL.a(SDL_cursor.o): In function `SDL_MouseRect':
SDL_cursor.c:(.text+0x164): undefined reference to `memcpy'
libSDL.a(SDL_keyboard.o): In function `SDL_PrivateKeyboard':
SDL_keyboard.c:(.text+0x390): undefined reference to `memcpy'
libSDL.a(SDL_surface.o): In function `SDL_GetClipRect':
SDL_surface.c:(.text+0x34c): undefined reference to `memcpy'
libSDL.a(SDL_surface.o): In function `SDL_LowerBlit':
SDL_surface.c:(.text+0x3e8): undefined reference to `memcpy'
SDL_surface.c:(.text+0x424): undefined reference to `memcpy'
libSDL.a(SDL_surface.o):SDL_surface.c:(.text+0x838): more undefined references to `memcpy' follow
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2\libgcc.a(unwind-arm.o): In function `unwind_phase2':
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.6.2/libgcc/../gcc/config/arm/unwind-arm.c:698: undefined reference to `abort'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2\libgcc.a(unwind-arm.o): In function `__gnu_Unwind_Resume':
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.6.2/libgcc/../gcc/config/arm/unwind-arm.c:885: undefined reference to `abort'
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.6.2/libgcc/../gcc/config/arm/unwind-arm.c:903: undefined reference to `abort'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2\libgcc.a(pr-support.o): In function `_Unwind_GetDataRelBase':
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.6.2/libgcc/../gcc/config/arm/pr-support.c:394: undefined reference to `abort'
c:/program files (x86)/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2\libgcc.a(pr-support.o): In function `_Unwind_GetTextRelBase':
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.6.2/libgcc/../gcc/config/arm/pr-support.c:400: undefined reference to `abort'
collect2: ld returned 1 exit status

212
TI-Nspire / Re: TI-Nspire emulator
« on: January 24, 2012, 04:27:17 pm »
There is an issue with documents not always sending although the user pressed "Connect". Although it's a bit of a surface fix, at least now every document should be sent once it's connected. (file attached)
It seems to have actually caused more of exactly what it was supposed to fix, at least on my side. Removed the attachment.

213
nSDL / Re: SDL for the TI-Nspire
« on: January 23, 2012, 06:30:04 pm »
Seems good, except I'm not sure if prematurely combining nonexistent libraries into one big group is a good idea. It would somehow feel like the beginning of a massive bloated library where everybody's dealing with about everything and no one's doing anything meticulously well. A library like SDL would be the foundation structure of other programs, and the said library should be like a razor sharp knife. It should be robust, clean, flexible while at the same time faster than the speed of light. I don't mind combining efforts, but I prefer to avoid it being included in some set with other libraries.

214
nSDL / Re: SDL for the TI-Nspire
« on: January 23, 2012, 07:54:08 am »
Quote from: jimbauwens on January 23, 2012, 07:37:26 am
Nice :)

But as said before, Albert and totorigolo are also busy with an SDL port.
Maybe you should contact them, and eventually work together?
But I thought you said (or whoever it was) that they were "looking" at it, from which I concluded they weren't actually writing any code.

215
nSDL / Re: SDL for the TI-Nspire
« on: January 23, 2012, 06:48:24 am »
Quote from: adriweb on January 23, 2012, 06:42:14 am
Aslo, Are you going to put it on GitHub or so as you're programming it ?
Yeah probably, but I'll set it up once I have something more concrete done.
https://github.com/Hoffa/TI-Nspire-SDL

216
nSDL / nSDL 1.1.1 Anniversary Edition—The Ultimate TI-Nspire Graphics Library
« on: January 23, 2012, 06:18:44 am »
SDL for the TI-Nspire

nSDL is a port of the widely used, cross-platform and open source SDL graphics library for the Ndless-fueled TI-Nspire.

nSDL 1.1.1 is here! Click here for the new updates.

To download the latest nSDL build and access the wiki, check out the nSDL website.

nSDL also has its own little wiki, which you can access by clicking here.

nSDL features:
  • Full one-binary-for-all support on every TI-Nspire calculator.
  • Very fast & stable buffered drawing.
  • Supports all graphics-related functions, events, non-threaded timer functions, and more.
  • Supports 8- and 16-bit display bit depth.
  • Supports resolutions up to 320 × 240.
  • Draw text using fonts you choose.
  • Load images directly from the executable (image converter included) or use BMPs.
  • SDL_image (supports GIF, LBM, PCX, PNM, TGA and XCF formats) and SDL_gfx available.
  • Full-featured sample program included (it has Link in it!).
  • Based on the robust SDL 1.2.15.






Links:

217
TI-Nspire / Re: [Lua] Mancala
« on: January 14, 2012, 05:10:33 am »
Quote from: epic7 on January 13, 2012, 09:28:00 pm
And also, is there an easy way to add something to the end of the table and count the number of things in a table?
Yeah, table.insert() and the # operator.

218
Gaming Discussion / Re: Help Choosing 10 GAMES
« on: January 08, 2012, 01:25:44 pm »
And I thought the 1st prize was every single game on Steam.

219
Computer Projects and Ideas / Re: Lua code optimizer for pc
« on: January 05, 2012, 07:59:10 pm »
Does changing \000 to \0 make any improvements speed-wise?

220
Lua / Re: Owl — A fast, lightweight, and flexible game engine for the TI-Nspire
« on: January 05, 2012, 03:59:18 pm »
Quote from: DJ_O on January 05, 2012, 03:03:53 pm
EDIT Weird I don't notice much of a frame difference. Is it just due to the getkey speed limitation and lack of smooth character movement?
Actually I just noticed that that TNS used the timer to refresh the screen every 0.01s (I was measuring the FPS), rather than updating after moving Link (I uploaded again and updated the link). I think why it doesn't seem to be that much faster is because of the key repeat limitation indeed. Also if I had used a map with loads of sprites you would have seen a huge improvement, but even now it should be quite a bit more responsive.

221
Lua / Re: Owl — A fast, lightweight, and flexible game engine for the TI-Nspire
« on: January 05, 2012, 03:10:04 pm »
Quote from: DJ_O on January 05, 2012, 03:03:53 pm
Interesting. Could you sum up how you got to improve the speed? Also does it use any undocumented tricks? Because maybe that won't work in future OSes then :(
Well it basically keeps track of tiles that need to be redrawn and only refreshes that part of the screen (which doesn't work on the official emulator). That speeds things up a lot. No undocumented stuff.
Edit: that also means that at some point I'll be able to add a feature to use animations for the characters, as it won't really slow things down.

222
Lua / Re: Owl — A fast, lightweight, and flexible tile map engine for the TI-Nspire
« on: January 05, 2012, 01:55:05 pm »
Just to let you know, Owl now runs at a good 50 FPS (from a previous 9 FPS) when not scrolling (thanks to jimbauwens for clearing me up).
Here is a small demo you can try out yourself to see how it runs speed-wise: http://bb.xieke.com/files/1/owl_test.tns
(The code itself is crappy, but I quickly did something dirty so I have a good base from which to write clean code)
It won't work on the official TI-Nspire emulator though, so you have to try it on the actual hardware if you want to actually see something. Also I changed Link to a Link that is the size of a tile (16x16 in this case), as it is currently too much of a mess to deal with arbitrary sized sprites.

223
Lua / Re: Owl — A fast, lightweight, and flexible tile map engine for the TI-Nspire
« on: January 03, 2012, 08:10:25 am »
Quote from: jimbauwens on January 03, 2012, 07:51:22 am
Your code works with me, although I did not use a fullscreen picture (32*32).
When pushing enter only a 10*10 square is cleared.

Edit:
Also, you can expect improvement in the next OS release.
TI did not create Lua for game programming, so its not hard to understand that its not optimized for games.
Anyway, I don't have any problem with TI.Image.
Actually I tried it on the official emulator, maybe the behavior is different on the actual hardware. Once I return home I'll try it on the calculator, so hopefully that was the reason why it didn't seem to work. Thanks for clearing that up anyway.
Hopefully they will indeed improve it in the next OS!

224
Lua / Re: Owl — A fast, lightweight, and flexible tile map engine for the TI-Nspire
« on: January 03, 2012, 07:44:29 am »
Quote from: Nick on January 03, 2012, 07:41:08 am
well, you make drawn true when painting, so when you press enter, the drawn isn't false anymore and the sprite won't get drawn, just change that drawn=true in =false (or just delete it) and it should work

the rest of the code is correct imo
Well that was to show that it does clear the screen every time, which is absolutely dumb speed-wise (i.e. I am forced to recopy all the data to the screen no matter what).
EDIT: If only TI had made their library simple and hassle-free like SDL, it would loads better.

225
Lua / Re: Owl — A fast, lightweight, and flexible tile map engine for the TI-Nspire
« on: January 03, 2012, 07:38:22 am »
Quote from: jimbauwens on January 03, 2012, 07:19:57 am
This is not the case if you only invalidate a certain spot (by giving arguments to invalidate() ).
I've made some stuff with it (smooth scrolling) and it works very good.
I'd like to see how you do that, as this simple example does clear the whole screen whenever I press the enter key:
Code: [Select]
sprite = image.new("some 318*212 ti image")
drawn = false

function on.enterKey()
    platform.window:invalidate(10, 10, 10, 10)
end

function on.paint(gc)
    if not drawn then
        gc:drawImage(sprite, 0, 0)
        drawn = true
    end
end

Pages: 1 ... 13 14 [15] 16 17 ... 21