Aslo, Are you going to put it on GitHub or so as you're programming it ?
Nice :)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.
But as said before, Albert and totorigolo are also busy with an SDL port.
Maybe you should contact them, and eventually work together?
#include <os.h>
typedef struct type1_t {
const char *s;
} type1_t;
typedef struct type2_t {
const char *s1;
const char *s2;
} type2_t;
int main(void) {
type1_t test1 = {"foobar"};
type2_t test2 = {"foo", "bar"};
printf("test1.s: %s\n", test1.s); /* Prints "foobar" */
printf("test2.s1: %s\n", test2.s1); /* Should print "foo"; doesn't */
printf("test2.s2: %s\n", test2.s2); /* Should print "bar"; doesn't */
return 0;
}test1.s: foobar
test2.s1: foo
test2.s2: bar.LC2:Which is not good, GCC doesn't make it relocatable by Ndless.
.word .LC0
.word .LC1
int main(void) {
type1_t test1 = {"foobar"};
type2_t test2 = {"foo", "bar"};
nl_relocdata((unsigned*)&test2.s1, 1);
nl_relocdata((unsigned*)&test2.s2, 1);
printf("test1.s: %s\n", test1.s); /* Prints "foobar" */
printf("test2.s1: %s\n", test2.s1); /* Should print "foo"; doesn't */
printf("test2.s2: %s\n", test2.s2); /* Should print "bar"; doesn't */
return 0;
}EDIT:
Windows 7 x64 and Yagarto that uses the following versions:
binutils: 2.21
gcc: 4.6.2
newlib: 1.19.0
gdb: 7.3.1
Seems that one would need to know ARM ASM to do itI doubt that it's necessary: AFAICT, the bFLT loaders in Linux and QEMU are plain C :)
Could somebody quickly check my code, it doesn't seem to print the value of f. Either I'm using nl_relocdata wrong, or then I'm too tired and am missing something silly.
http://pastebin.com/N2iiUhd1 (http://pastebin.com/N2iiUhd1)
That's more or less how SDL behaves at one point, and it's reallocating the function pointer that causes issues. The strings print out fine, calling the function doesn't work though.
EDIT: I've tried everything I can think of. Am I really missing something here or is there no way to use nl_relocdata on a pointer to a function? (I doubt it, even in the wiki it is mentioned)
Once we get a firm grasp on the USB hardware (apparently BrandonW is getting really close) it might be a good idea to try supporting USB audio.Great !
--- old/binfmt_flat_mod.c 2012-02-12 20:25:14.000000000 +0100
+++ binfmt_flat.c 2012-02-14 18:54:14.624405087 +0100
@@ -15,40 +15,12 @@
* JAN/99 -- coded full program relocation ([email protected])
*/
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/sched.h>
-#include <linux/mm.h>
-#include <linux/mman.h>
-#include <linux/errno.h>
-#include <linux/signal.h>
-#include <linux/string.h>
-#include <linux/fs.h>
-#include <linux/file.h>
-#include <linux/stat.h>
-#include <linux/fcntl.h>
-#include <linux/ptrace.h>
-#include <linux/user.h>
-#include <linux/slab.h>
-#include <linux/binfmts.h>
-#include <linux/personality.h>
-#include <linux/init.h>
-#include <linux/flat.h> // This and arch/arm/include/asm/flat.h contain interesting stuff.
-#include <linux/syscalls.h>
-
-#include <asm/byteorder.h>
-#include <asm/system.h>
-#include <asm/uaccess.h>
-#include <asm/unaligned.h>
-#include <asm/cacheflush.h>
-#include <asm/page.h>
-
/****************************************************************************/
// Until the code has production status...
#define DEBUG 1
-// We'll probably want both compressed files, and bFLT libraries
+// We want both compressed files, and bFLT libraries
#define CONFIG_BINFMT_ZFLAT
#define CONFIG_BINFMT_SHARED_FLAT
@@ -96,27 +68,6 @@
static int load_flat_binary(struct linux_binprm *, struct pt_regs * regs);
static int flat_core_dump(struct coredump_params *cprm);
-// TODO REMOVE Linux-specific
-static struct linux_binfmt flat_format = {
- .module = THIS_MODULE,
- .load_binary = load_flat_binary,
- .core_dump = flat_core_dump,
- .min_coredump = PAGE_SIZE
-};
-
-/****************************************************************************/
-/*
- * Routine writes a core dump image in the current directory.
- * Currently only a stub-function.
- */
-// TODO REMOVE Linux-specific
-static int flat_core_dump(struct coredump_params *cprm)
-{
- printk("Process %s:%d received signr %d and should have core dumped\n",
- current->comm, current->pid, (int) cprm->signr);
- return(1);
-}
-
/****************************************************************************/
/*
* create_flat_tables() parses the env- and arg-strings in new user
@@ -550,10 +501,8 @@
*/
DBG_FLT("BINFMT_FLAT: ROM mapping of file (we hope)\n");
- down_write(¤t->mm->mmap_sem); // TODO REMOVE
textpos = do_mmap(bprm->file, 0, text_len, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_EXECUTABLE, 0); // TODO PORT we'll probably read everything to RAM
- up_write(¤t->mm->mmap_sem); // TODO REMOVE
if (!textpos || IS_ERR_VALUE(textpos)) {
if (!textpos)
textpos = (unsigned long) -ENOMEM;
@@ -564,10 +513,8 @@
len = data_len + extra + MAX_SHARED_LIBS * sizeof(unsigned long);
len = PAGE_ALIGN(len);
- down_write(¤t->mm->mmap_sem); // TODO REMOVE
realdatastart = do_mmap(0, 0, len,
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 0); // TODO PORT we'll probably copy everything to RAM
- up_write(¤t->mm->mmap_sem); // TODO REMOVE
if (realdatastart == 0 || IS_ERR_VALUE(realdatastart)) {
if (!realdatastart)
@@ -611,10 +558,8 @@
len = text_len + data_len + extra + MAX_SHARED_LIBS * sizeof(unsigned long);
len = PAGE_ALIGN(len);
- down_write(¤t->mm->mmap_sem); // TODO REMOVE
textpos = do_mmap(0, 0, len,
PROT_READ | PROT_EXEC | PROT_WRITE, MAP_PRIVATE, 0); // TODO PORT we'll probably read everything to RAM
- up_write(¤t->mm->mmap_sem); // TODO REMOVE
if (!textpos || IS_ERR_VALUE(textpos)) {
if (!textpos)
@@ -962,16 +907,3 @@
return 0;
}
-
-/****************************************************************************/
-// TODO REMOVE Linux-specific
-static int __init init_flat_binfmt(void)
-{
- return register_binfmt(&flat_format);
-}
-
-/****************************************************************************/
-
-core_initcall(init_flat_binfmt);
-
-/****************************************************************************/and I don't have time to undertake such a task alone - for a start, not this evening.
Anyway, on a side note, that whole Ndless-being-blocked-in-3.2 thing gave me quite a blow to the head. I have to admit I'm pretty fucking frustrated; I expected it but didn't think it'd come this quickly. Right now I feel like the work I'm doing is completely useless, and realistically speaking it is. It may take a month (or more) to have a first more or less stable version of SDL, from then on it takes time for people to learn the library/port programs. At that time 3.2 will be out, it'll be the shiny new thing and 3.1 will be outdated. Even I won't feel like staying on an "old" platform developing for a tiny minority. Even if I'd like to, I can't, as I'm getting my ass conscripted for about a year in the Finnish Army (yes I'm Finnish and we have conscription), and after that I'm moving to the UK for my university studies. There I will hardly ever use my TI-Nspire and will most probably develop on other platforms. I will try to finish this thing even for the sake of it (and to be able to add "ported SDL to a calculator" on my CV). Just realized it'll possibly be my last project on a calculator, but we'll see how it eventually turns out.:(
Nice, keep up the good work! ;)Depends what exactly are the libraries used by VBA, but sure, with some trimming it shouldn't be too big of an issue.
Also, will it be possible to port VisualBoyAdvance? It's SDL-based. :D
Nice, keep up the good work! ;)
Also, will it be possible to port VisualBoyAdvance? It's SDL-based. :D
Also Hoffa, how are you handling the fact that the timer is 16-bit? I think the SDL_GetTicks() is supposed to return a 32-bit value.Well currently I just convert the timer value to milliseconds and return it. I should indeed return the number of milliseconds since SDL was initialized, and simulating a 32-bit timer is rather painstaking with a 16-bit timer unless I somehow periodically check for overlaps and add that to the overall value. I might do it sometime later, but currently it would unnecessarily complexify the code, it would be too much hassle for something that isn't that big of an issue. Currently the timer precision is only at 10 Hz (i.e. 0.1s precision), but that gives ~1.8 hours without a timer reset. I doubt anyone uses the same program on a calculator that long anyway, so I guess I'll increase the timer to 20 Hz (or more) tomorrow.
Hoffa, how did you get the boot 1 for the cx? I don't have a cx, but I've been wanting to use one with nspire_emu. I just have a regular nspire, but it would be nice to have an nspire cx on the nspire_emu.I got it off someone else. Drop me a PM and I'll send it to you tomorrow.
Todo:
- Add SDL_GetTicks() for CX
- Map more keys to SDLKs
- Add support for diagonal arrow keys in events & joystick
- Should the joystick continuously fire events if an arrow key is held down?
- Put all the compiled objects in one folder, along with libSDL.a?
- Add some own function to load images stored in arrays (?)
- Add mouse supportA few of those are trivial to do, but as you can see there's not much left before a beta, if everything goes well and if I don't find any other issues.
While I'm dealing with the timer stuff, I decided to implement fonts. There are 4 fonts included by default, but it's easily extensible. See for yourself:
(http://i.imgur.com/BG1zZ.png)
Drawing fonts is as easy as calling the SDL_NSP_DrawString() function (any TI-Nspire-specific functions I add will be prefixed with SDL_NSP_*).
Yes, or more generally, I fixed most of the blitting issues. Here's a short video so you can more or less see how blitting a big image runs speed-wise:
EDIT: I actually forgot to pass the surface through SDL_DisplayFormat() to convert to the screen's pixel format. With SDL_DisplayFormat() it's a lot snappier.
EDIT2: Here's another video that gives a better impression of the blitting speed (and seems like there are some issues with timers I need to fix):
Is nSDL far enough to start porting SDL programs to the nspire? Or do you need to do more work? (I know nothing about SDL, so I have no clue what you have to do to finish it) Also, could I put custom fonts off of my computer on my nspire using nSDL without having to make the font over again?I wouldn't say it is yet. Depends what programs of course, but a few crucial things are missing, and it needs some testing (but that's when it comes to porting more sophisticated programs in the current state; writing your own shouldn't be that big of an issue though). Also many programs use floating point math, and it doesn't seem like Ndless in its current states supports any of that. I'd say if everything goes nicely there might be an early beta at the end of the week.
It's working very well, and the timer is very accurate! :DGood 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.
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.Sure :)
On a side note, I'm working on getting SDL_image to run, i.e. support for a lot of different image formats.Nice :)
SDL is written in C, but works with C++ natively
Compatibility of Ndless with Newlib has not been tested. You may get definition conflicts and crashes due to Newlib running without the required relocation that Ndless doesn't provide. You should always build your programs with the nspire-ld flag -nostdlib, except if you need the single precision floating-point helper functions internally called by GCC when required (__aeabi_fadd, ...).
I'd prefer that both of you contribute to find out the root cause of the issue.I'll have a more thorough look at it tomorrow (or whenever I have the time). I checked newlib's sqrt() implementation (http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/newlib/libm/math/e_sqrt.c?rev=1.1.1.1&content-type=text/plain&cvsroot=src) (I'm pretty sure that's the one used), and there doesn't seem to be any global variable stuff that could cause issues.
I'd prefer that both of you contribute to find out the root cause of the issue.Yes, there are a few things that doesn't seem to work with Ndless, like srand(int) and rand();
atiatinini, if you are trying to port SDL programs, you'll probably encounter other conflicts more difficult to identify and work around.
The source code of Newlib's sqrt is this one:Can't Newlib "just" be recompiled with some nl_relocdata hacking meanwhile?
http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libm/math/w_sqrt.c?annotate=1.1.1.1&cvsroot=src
_LIB_VERSION refers to the global variable __fdlib_version, I'm not sure why but it seems to require relocation, which cannot be provided by Ndless.
It actually doesn't work well without nSDL, it's just that the random access to memory falls to a valid address (but still not __fdlib_version).
I'm afraid we cannot trust any Newlib function without a full-featured relocator.
8 BPP support for CX (thanks to atiatini for the idea; makes it possible to port 8 BPP programs for the CX),FWIW, while their screen sucks beyond usability, the Clickpad & Touchpad models do support 8 bpp, as shown by nDOOM :)
many font-related changes (if you're the observing type you can notice one thing on the screenshot below)Transparency ?
In this case it's software 8 BPP for CX (i.e. if 8 BPP used, the 8->16 conversion is done at the very end), the same way as it's software 8 BPP for Touchpad/Clickpad (8->4 conversion done at the end). I indeed read that it was possible to change the bit depth on the grayscale display, but I suppose the screen'll still only have 16 shades of gray, and the advantages of switching to hardware 8 BPP are limited (not sure how it would behave in weird situations or sudden crashes).Quote8 BPP support for CX (thanks to atiatini for the idea; makes it possible to port 8 BPP programs for the CX),FWIW, while their screen sucks beyond usability, the Clickpad & Touchpad models do support 8 bpp, as shown by nDOOM :)
Nope, that should already work with SDL_SetAlpha(). It's non-monospaced fonts (e.g. see "quick"). I acknowledge the font isn't the best to show that, but it wasn't the point either.Quotemany font-related changes (if you're the observing type you can notice one thing on the screenshot below)Transparency ?
but I suppose the screen'll still only have 16 shades of gray,AFAICT (from watching DummyOS changing colors smoothly enough), the grayscale screen can do 256 shades of gray... or at least, it can do more than 16 shades :)
and the advantages of switching to hardware 8 BPP are limited (not sure how it would behave in weird situations or sudden crashes).(emphasis mine)
It's non-monospaced fontsOh yeah, that's good :)
AFAICT (from watching DummyOS changing colors smoothly enough), the grayscale screen can do 256 shades of gray... or at least, it can do more than 16 shades :)If that's true, I might be more inclined to try 8 bpp out.
The normal 320 x 240 x 4 bpp screen area is stored in SRAM, but the 320 x 240 x 8 bpp area cannot be stored there, it needs to be stored in SDRAM. Upon exit, one has to make sure that the memory is freed and the screen base address pointer is restored, otherwise funny stuff will occur.If I have some documentation and facts I can rely on, it should be very possible to implement. SDRAM should never be read anyway, in nSDL's case all reads go through the buffer. I could just write some experimental code through a bunch of #if's like I've been doing until now and add a static library to the list (libSDL-TC8.a or something) for those who want to try it out. It might very well be that the advantages of having a 8 bpp display outweight the disadvantages of the rare occasion when the calculator explodes because of access violations.
And reading from display memory stored in SDRAM might have some unwanted effects (-> critor ?).
The case for hardware 8 bpp mode, on Clickpad & Touchpad, would be to reduce the risk that Clickpad & Touchpad users are left in the cold for SDL-based programs.How so left in the cold?
SDRAM should never be read anyway, in nSDL's case all reads go through the buffer.Yup, but nSDL itself has to read from the buffer stored in SDRAM, and there might be some quirks in doing so. I vaguely remember something about that, but I'll stop talking about that matter until someone more knowledgeable than I am (e.g. critor, on that aspect) has a more definitive input :)
How so left in the cold?8 bpp is much more usable than 4 bpp for graphics. IMO, chances are that more people will care about Clickpad & Touchpad compatibility if they support 8 bpp, than if they support only 4 bpp :)
Just to give you a quick heads up, the next version--0.2.0--and rather major step, will have numerous changes. Among those will be mouse support, 8 BPP support for CX (thanks to atiatini for the idea; makes it possible to port 8 BPP programs for the CX), many font-related changes (if you're the observing type you can notice one thing on the screenshot below) and a lot of under-the-hood modifications (performance, stability, etc.). Also a few surprises. Quick screenshot to show 16 BPP and palettized 8 BPP on CX (actually it's just an excuse to give the thread some color):Wow nice. 8 bit support would be great for game sprites especially, to save space. ALso for large images on the small screen, if you use dithering, the quality drop won't be as noticeable. :)
(http://i.imgur.com/1RGtr.png)
Also the mouse seems nice. How is the touchpad sensitivity? I know the cursor of the one in the OS stutters a lot when I move the finger around, but maybe it was the OS fault.
Wow that looks great. :D When this is available for download, I need to try the color version to see how this looks like on my CX (assuming a demo of the above is made available?). :DOf course! :D
You'd have to fill the palette RAM with 256 grayscale color valuesOh of course, I was thinking about that.
each from 15 (black) to 0 (white)So there after all is only 16 colors available? My main reason to even try to switch to 8 bpp is for some extra shades of gray, the speed increase is negligible.
However, I think a 256-entry palette mode could still be useful, as nDoom used that even in its original grayscale form.In what way could it be useful? In its current form SDL uses a 256-color software palette; the result is exactly the same whether using software or hardware palette.
The values change when I use the touchpad but the mouse doesn't appear. :(That's normal, I disabled the mouse so that I can only read raw values (no SDL involved except for the font drawing). So it seems it does update it normally. I think the problem might be similar to the one had some time ago. Thanks a lot, I'll look into it. :)
Amazing! :)Should be exactly the same as the result is the same (SDL_Surface).
Just wondering, how's the performance of this compared to BMP blitting?
Off-topic: Those tiles are nice. Are they from a game in particular or did you make them yourself?Some free ones I found somewhere I can't remember.
is SDL easier to program than nspire c/asm?Well it still is in C. But yes, it is much easier than doing everything from scratch. Also SDL's quite mature and there's a lot of resources and information available on the Internet about it, that's always good.
Any progress in C++ support? :)No idea, I'm not the one dealing with that. I don't think anyone is working to get C++ on the TI-Nspire.
Very nice :DThere's practically no difference.
Also, since it's a "universal binary", what the size difference with the version before ? Probably not much ? (which means it's easier anyway for the programmer/user)
We can easily port only:Also resolution should be taken into account, as nSDL handles resolution <= 320x240. Oh and global variables can be a source of frustration on bigger programs as there's no stable loader currently. Thankfully GP32/GP2X and some other machines have many games, use SDL, have a 320x240 resolution and many (most?) of the games are written in C. Oh and of course all the DOS clones/ports in SDL (C-Dogs, OpenTyrian and whatnot) and generic flexible SDL games.
- games whose source code is available
- games which relies on the SDL library
- games which doesn't use assembly (between an MS-DOS and a Linux version of the same game, we should choose to work on the Linux version)
- games written in C (no C++)
Please correct me if I'm wrong:To address some points:
We can easily port only:
- games whose source code is available
- games which relies on the SDL library
- games which doesn't use assembly (between an MS-DOS and a Linux version of the same game, we should choose to work on the Linux version)
- games written in C (no C++)
Meaning that until we've got a C++ toolchain for Ndless, most of the greatest SDL games/emulators can't be ported?...
I do not know of its status, and whether or not it has merged with the official ndless treeIt has not yet.
There's one little thing that I'd like to see implemented before it gets off: replacing library IDs with Java-style names.If it cannot be done with standard bFLT (and I'm not aware it can be done), it's unlikely to be something we want to do: hacked up formats require non-standard toolchains, which are a maintenance burden in the long term ;)
Ahh... if only I had time to work on this :/ (I have college-like finals, aka CollegeBoard AP tests this week.)QuoteI do not know of its status, and whether or not it has merged with the official ndless treeIt has not yet.
If it cannot be done with standard bFLT (and I'm not aware it can be done), it's unlikely to be something we want to do: hacked up formats require non-standard toolchains, which are a maintenance burden in the long term ;)True :) Well... I guess we could reserve a few numbers for ndless' core and particular important libraries, and then use some kind of ID manager for the rest. I just hope implementing all of this won't get too messy...
I hardcoded (using a simple script) the map data in the program and compiled it. Magic happened:I tried it on my CX, then with one of my friend, we couldn't stop playing in two player mode :PI've attached the game here in my post. I'd appreciate it if someone with a CX could try it (just dump the whole folder in the Examples folder on the TI-Nspire) and tell me how it runs. Even better would be to upload a video about it. If you have a Touchpad/Clickpad you can try it too, but the games' colors are quite dark; I couldn't see much (that made me think of a function that inverts the palette...hmm).Spoiler For Spoiler:
The controls are CTRL, tab, arrow keys (player 1) and 8/2/4/6, enter (player 2). Yes there's 2 player mode also.
I hardcoded (using a simple script) the map data in the program and compiled it. Magic happened:I tried it on my CX, then with one of my friend, we couldn't stop playing in two player mode :PI've attached the game here in my post. I'd appreciate it if someone with a CX could try it (just dump the whole folder in the Examples folder on the TI-Nspire) and tell me how it runs. Even better would be to upload a video about it. If you have a Touchpad/Clickpad you can try it too, but the games' colors are quite dark; I couldn't see much (that made me think of a function that inverts the palette...hmm).Spoiler For Spoiler:
The controls are CTRL, tab, arrow keys (player 1) and 8/2/4/6, enter (player 2). Yes there's 2 player mode also.
However, would it be possible to remap the keys for the first player (or maybe the two players) ? Because the Touchpad sucks a lot.
EDIT: I'll make it touchpad and/or numpad in single player, and only touchpad in co-op.Good idea :)
What keys would you suggest? I admit my touchpad is crap too (feels very unresponsive and soft).Else, you could also use the numpad for player one and some of the bottom keys for the second player, like I for up, W for down, ',' for left, R for right and Space to shoot ?
I'm not sure if playing with the tiny buttons is more comfortable than with the touchpad. I think I'll keep it touchpad/numpad in the first version at least, and later I'll look into external config files if I have the time. Meanwhile, here's a screenshot of the improved version I'm working on:What keys would you suggest? I admit my touchpad is crap too (feels very unresponsive and soft).Else, you could also use the numpad for player one and some of the bottom keys for the second player, like I for up, W for down, ',' for left, R for right and Space to shoot ?
Or something even better would be to make several key_config external files (like the ones we must put in Examples) that the game would load, and according to which one we have, the key configuration is not the same. But that may be a bit annoying to do for you :-\
I'm not sure if playing with the tiny buttons is more comfortable than with the touchpad. I think I'll keep it touchpad/numpad in the first version at least, and later I'll look into external config files if I have the time.Yeah, I thought it would be hard too but in fact, once you placed your fingers on the keys, you don't move them a lot in this type of game. Moreover, the touchpad doesn't allow to push on two directionnal keys at a time (this is why my friend beat me the third time :P) and doesn't allow you to keep two fingers on the "buttons" :(
(http://webgel.net/bf/1/dd2x.png)/me wants O.O
Maybe you're right. Being unable to move diagonally is a good argument actually, so I guess I'll do it numpad for player 1 and keyboard for player 2. It'll leave the Clickpad users out for (playable) two player mode, but once I release nSDL 0.3.1 there'll be diagonal touchpad key support too, which will probably make me update this and switch back.I'm not sure if playing with the tiny buttons is more comfortable than with the touchpad. I think I'll keep it touchpad/numpad in the first version at least, and later I'll look into external config files if I have the time.Yeah, I thought it would be hard too but in fact, once you placed your fingers on the keys, you don't move them a lot in this type of game. Moreover, the touchpad doesn't allow to push on two directionnal keys at a time (this is why my friend beat me the third time :P) and doesn't allow you to keep two fingers on the "buttons" :(
...but once I release nSDL 0.3.1 there'll be diagonal touchpad key support too, which will probably make me update this and switch back.Or make those config files :P
(http://webgel.net/bf/1/dd2x.png)
I really hope when nSDL comes out that it will help bringing an influx of new Ndless games to the community.I hope so too, but the hard fact is that TI will release OS 3.2 before nSDL usage by programmers has a chance to really take off...
I wonder if a port of Dosbox would be possible using this.Possible, maybe... but I'm not so sure that it would be usable for anything but the 8086 and the slower 80286 versions, as the poor little ARM CPU in the Nspire is not very powerful. Each core of the newest ARM CPUs does an order of magnitude better than the Nspire's CPU.
WOn't you work on SDl's addons? That would be quite useful!Yessir!
Is there any way of easily finding where you made changes to the SDL source? I would like to look a little to see what it takes to port it to a new platformSure. Check out the source code here: https://github.com/Hoffa/nSDL (https://github.com/Hoffa/nSDL)
Wow that looks great. :D When this is available for download, I need to try the color version to see how this looks like on my CX (assuming a demo of the above is made available?). :DOf course! :D
CX:
http://www.mediafire.com/?7omfqojuxjjrpp2
Touchpad/Clickpad:
http://www.mediafire.com/?ax8dyd9xqgjb2z5
And here's the source (just ignore my dirty random generator at the end):
http://pastebin.com/gqjXDTBw
Also, please note that the actual code that generates the plasma effect was not made by me, this is just a port of a demo available here (http://www.libsdl.org/projects/plasma/).
fdlibm eh? Gotta try on the Prizm. Unless someone manages to make it work with newlib.Yeah you should be able to compile it easily using the code from here (https://github.com/Hoffa/nSDL/tree/master/tinspire/libs/fdlibm-1.5-r2). I'm not sure if there are any issues with globals on the Prizm, but that code should compile perfectly on any platform, just edit the Makefile a bit (and rename the resulting libm.a to libfdm.a to avoid doubts and name collisions). Oh and in fdlibm.h, remove the #ifdef _TINSPIRE/#endif at the top.
He finally got it working with -lm :)Damn that's awesome!
Here's the game he ported : http://tiplanet.org/forum/viewtopic.php?p=126303#p126303
so I heard that there's a gba emulator using SDL or something (at least I think that's what calc84maniac said before). Will it be possible to port it to nspire?I'm already porting it (and I removed all SDL references as well, since it's mainly used for the framebuffer)
so I heard that there's a gba emulator using SDL or something (at least I think that's what calc84maniac said before). Will it be possible to port it to nspire?I'm already porting it (and I removed all SDL references as well, since it's mainly used for the framebuffer)
Hello,I do not think so if I remember from when I looked through the code its a hardcoded value
Is it possible to increase the size of letters drawn by nSDL_DrawStr() ?
Thank you,
Torio
Let's just hope there'll be an influx of new Nspire programmers.Sadly, unlikely: the next OS version will certainly set the anti-downgrade protection high enough to prevent going back to OS 3.1.0.392.
void setPixel(SDL_Surface *surface, int x, int y, Uint32 pixel)
{
int bpp = surface->format->BytesPerPixel;
Uint8 *p = (Uint8 *)surface->pixels + y * surface->pitch + x * bpp;
switch(bpp) {
case 1:
*p = pixel;
break;
case 2:
*(Uint16 *)p = pixel;
break;
case 3:
if(SDL_BYTEORDER == SDL_BIG_ENDIAN) {
p[0] = (pixel >> 16) & 0xff;
p[1] = (pixel >> 8) & 0xff;
p[2] = pixel & 0xff;
} else {
p[0] = pixel & 0xff;
p[1] = (pixel >> 8) & 0xff;
p[2] = (pixel >> 16) & 0xff;
}
break;
case 4:
*(Uint32 *)p = pixel;
break;
}
}
Uint32 getPixel(SDL_Surface *surface, int x, int y)
{
int bpp = surface->format->BytesPerPixel;
Uint32 value;
Uint8 *p = (Uint8 *)surface->pixels + y * surface->pitch + x * bpp;
switch(bpp) {
case 1:
value = *p;
break;
case 2:
value = *(Uint16 *)p;
break;
case 3:
if(SDL_BYTEORDER == SDL_BIG_ENDIAN) {
value = (p[0] & 0xff) | (p[1] << 8) | (p[2] << 16);
} else {
value = (p[2] & 0xff) | (p[1] << 8) | (p[0] << 16);
}
break;
case 4:
value = *(Uint32 *)p;
break;
}
return value;
}
void nSDL_BlitSurfaceAlpha(SDL_Surface *src, SDL_Rect *srcRect, SDL_Surface *dst, SDL_Rect *dstRect, Uint16 alpha)
{
int x,y;
Uint32 color;
SDL_LockSurface(src);
SDL_LockSurface(dst);
for(y = 0 ; y < srcRect->h ; y++)
{
for(x = 0 ; x < srcRect->w ; x++)
{
if((Uint16)(color = getPixel(src, x + srcRect->x, y + srcRect->y)) != alpha)
{
setPixel(dst, x + dstRect->x, y + dstRect->y, color);
}
}
}
SDL_UnlockSurface(src);
SDL_UnlockSurface(dst);
}char curDir[256];
strncpy(curDir, argv[0], strflc(argv[0], '/'));
chdir(curDir);
...
size_t strflc(const char *src, char character)
{
size_t offset = strlen(src) - 1;
while(offset > 0)
{
if(src[offset] == character) break;
offset--;
}
return offset;
}Yeah that must be because of the way ndless (or syscalls, whatever) handle opening files (at some point in the code it's just calling fopen). Rather than implementing the relative path thing in nSDL, I think it would be better to do it in the fopen code itself for consistency across all programs. Despite that, I've never had to use "/documents/Examples/derp.bmp.tns" as the path, "Examples/derp.bmp.tns" has always worked IIRC.
- In my program, I'm loading a bitmap with SDL_LoadBMP(path), but it seems that relative path doesn't work. If I have image.bmp.tns in the same directory as my program, just typing SDL_LoadBMP("image.bmp.tns"); doesn't work. Is there a way to fix that ?
The format itself doesn't support transparency (neither does BMP), but SDL does support color keys for surfaces, and that's what you should be using. In the image, draw (in Paint or whatever) the parts that you want transparent with a certain color (#ff00ff is quite common) and after you've loaded it and have its SDL_Surface, do SDL_SetColorKey(surface, SDL_SRCCOLORKEY, SDL_MapRGB(screen->format, 0xff, 0x00, 0xff)). More info here (http://www.libsdl.org/docs/html/sdlsetcolorkey.html).
- Second question, I have sprites that have transparent parts, but it seems that transparency isn't supported due to the NTI format and get replaced by white 0xffff. Is there a way to use transparent sprites or are they forbidden ?
(new page, can't raise awareness like this)Maybe because you raged like hell on paint with some words some people might be shocked ? :o
Everybody! Look at this! This violates all international humanitarian laws: http://ourl.ca/14975/333020 (http://ourl.ca/14975/333020)How is debugging property of EMI?Probably because I used "Don't Worry, Be Happy" as the background music.
(maybe you were listening to some music during the debug session and youtube spotted them?)
There's no such thing as nDraw. Blitting (or "drawing" as I referred it to) is all part of standard SDL.So the picture on the first page no longer applies then.
ExtendeD I really would like you to fix the relocation issues, it's unbelievably horrible (but I suppose you know more than well enough the feeling I'm feeling right now, so no hurry).
Here's nSDL drawing the OpenBSD fish loaded from a GIF file:
Dunno, I just saved the file as a GIF on Paint. Can you post the file here?Here's nSDL drawing the OpenBSD fish loaded from a GIF file:
How did you make it to have the right colours from a gif file ? I'm loading a gif image from /documents/Examples/map.gif and it doesn't have the right colours at all ... Have I to save it as a gif with 16-bits colours ? If so, how can you do it with Gimp ?
Yeah, that would be a perfect candidate for tilemapping.^ I don't understand that :/ (sorry, French inside)
Of course I could, as for every SDL command ._. but since it can be optimized to work together with SDL, why do not ask hoffa ?The picture would be good for tilemapping because there are a lot of repeated patterns in there.
Also,Yeah, that would be a perfect candidate for tilemapping.^ I don't understand that :/ (sorry, French inside)
Of course I could, as for every SDL command ._. but since it can be optimized to work together with SDL, why do not ask hoffa ?The picture would be good for tilemapping because there are a lot of repeated patterns in there.
Also,Yeah, that would be a perfect candidate for tilemapping.^ I don't understand that :/ (sorry, French inside)
I actually looked at SDL2, and I've been waiting for a long time for a stable version to come out (even for one PC project I'm working on that uses SDL2). Even when does come out, SDL2 has very little to add to a machine such as the TI-Nspire, expect maybe for the included drawing (lines and whatnot) functions.yeah I see how SDL2 is more for higher power devices. I don't think there's much added that you can't easily implement as a side part.
As far as example programs are concerned, that's a very good point, and there'll be included sample(s) in the next release.
EDIT: Maybe you should initialize SDL as 8 bpp? nSDL handles 8 bpp on CX, and as you're only dealing with 8 bpp stuff it would maybe be easier to concentrate only on one bit depth?
BTW, about the SDL_GetTicks() issue you mentioned earlier, it was my fault. I had completely forgotten to uncomment a line in nSDL that enabled bus access for the timer, and consequently it worked on the emulator but not one the actual hardware (i.e., it returned always 0). It was extremely dumb and careless from me, but I've updated it now, SDL_GetTicks() should work now (I've tested it on both physical calculators, everything runs smoothly).
Oh wow, well I'm glad I found out about this before leaving. There was one big issue with 1.1.0; I'll quote:Woo, glad to here that issue is fixed! I guess I can start a (not so) secret porting project again! ;)BTW, about the SDL_GetTicks() issue you mentioned earlier, it was my fault. I had completely forgotten to uncomment a line in nSDL that enabled bus access for the timer, and consequently it worked on the emulator but not one the actual hardware (i.e., it returned always 0). It was extremely dumb and careless from me, but I've updated it now, SDL_GetTicks() should work now (I've tested it on both physical calculators, everything runs smoothly).
Let's just pretend that 1.1.0 never existed. :ninja:
What program is this picture?As said above.
http://i.imgur.com/ONKjZ.png
Overview of new features
These are the most important new features in SDL 2.0:
Full 3D hardware acceleration
Support for OpenGL 3.0+ in various profiles (core, compatibility, debug, robust, etc)
Support for OpenGL ES
Support for multiple windows
Support for multiple displays
Support for multiple audio devices
Android and iOS support
Simple 2D rendering API that can use Direct3D, OpenGL, OpenGL ES, or software rendering behind the scenes
Force Feedback available on Windows, Mac OS X and Linux
XInput and XAudio2 support for Windows
Atomic operations
Power management (exposes battery life remaining, etc)
Shaped windows
32-bit audio (int and float)
Simplified Game Controller API (the Joystick API is still here, too!)
Touch support (multitouch, gestures, etc)
Better fullscreen support
Better keyboard support (scancodes vs keycodes, etc).
Message boxes
Clipboard support
Basic Drag'n'Drop support
Proper unicode input and IME support
A really powerful assert macro
zlib license instead of LGPL.
Lots of old annoyances from 1.2 are gone
Many other things!
Since SDL 2.0 is now out, what benefits would it offer to the Nspire once you port it?Yeah, but beware that the porting effort of most of the current SDL apps wouldn't be that straightforward without a lot of source recoding. So, not all that glitters is always gold. I mean, SDL 2.0 is NOT backwards-compatible with SDL 1.2. :P
hoffa, do you have a sample program showing this?Yeah, attached. Sorry for the late reply, have been insanely busy.
May you attach the source as well ? (or a link since it looks like it's Mode7)hoffa, do you have a sample program showing this?Yeah, attached. Sorry for the late reply, have been insanely busy.
See what you"re doing, TI!That's one of their goals...
I found out that nSDL_GetPixel(SDL_Surface*, int, int) is incompatible with surfaces loaded with SDL_LoadBMP(char*) :/ it works with images loaded by IMG_Load(char*) though.
No, it's a classical 24-bits bitmap.
Returns the pixel's color at (x, y). Assumes the surface has been locked. Does no clipping. Supports 8-, 16- and 32-bit surfaces.
Hoffa are you (still) in Australia? How's life over there? Lotsa chicks? ;)@hoffa ! <3Damn that's some really old stuff (the tile map game engine thing, renamed it to Owl later). I think I had a thread here before yeah, but nobody seemed to care and I couldn't bear the responsibility of maintenance (or something) so I just deleted everything (I think I have a backup somewhere though).
I tested your "coyote demo" uploaded on TI-planet, did you made a topic for it ?
Check this out:I like the spoiler a lot ;) ! Welcome back and please do post some of your adventures in Your Highness' kingdom.
http://www.omnimaga.org/ti-nspire-projects/nsdl-2/msg383149/#msg383149 (http://www.omnimaga.org/ti-nspire-projects/nsdl-2/msg383149/#msg383149)Spoiler For Spoiler:
void draw_tile(SDL_Surface *tileset, long tile_num, int x, int y)
{
SDL_Rect src_rect, screen_pos;
src_rect.x = tile_num * 10 + 8;
src_rect.y = tile_num / 30 * 10 + 119;
src_rect.w = TILE_WIDTH;
src_rect.h = TILE_HEIGHT;
screen_pos.x = x * TILE_WIDTH;
screen_pos.y = y * TILE_HEIGHT;
SDL_BlitSurface(tileset, &src_rect, screen, &screen_pos);
}