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 2 [3] 4 5 ... 22
31
« on: January 29, 2013, 06:24:39 pm »
Tiny update after a long pause. Changes: - Compiled with nSDL 1.1.1 - Changed background - Added FPS counter (toggle with the I-key) - Uhh... that's it It runs at 30-40 FPS on CX, 50-60 FPS on Touchpad (but don't even bother with that one, the LCD is such a piece of shit it's only an ugly blurry mess). I haven't even bothered to optimize whatsoever. Also a gameplay video: EDIT: Check out the one below for a newer one Source code available here. Download attached.
33
« on: January 29, 2013, 03:39:14 pm »
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: 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.  Anyway, updated, download available on the website, you know the drill. EDIT: Oh, by the way, I also wrote an online image-to-NTI converter. It does exactly the same thing as the program included in nSDL, except it's faster for massive images and does no formatting whatsoever (which means a smaller source file): http://hoffa.franceserv.fr/nti/
34
« on: January 29, 2013, 03:35:16 pm »
Awesome!
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 calculators, everything runs smoothly).
35
« on: January 27, 2013, 12:28:15 pm »
I am using my own 16.16 fixed point number routines in most of the code. It should be faster than using a library because I can write only the features I need for this.
Maybe, but I doubt it is faster. Many of the libraries use very clever hacks, such as this one that even uses ARM assembly.
36
« on: January 27, 2013, 11:47:14 am »
I'm pretty positive you could get a nice speed boost if you used one of the many available fixed-point math libraries in C, especially if the program messes around a lot with floating point data (the ARM doesn't have an FPU).
37
« on: January 21, 2013, 06:28:14 pm »
I'm using nspire_emu_easy from Ti-Planet, it's a version with Ndl3ss already in it. Do you think it could be the wrong version ?
I'm pretty sure that's the all-in-one nspire_emu package I made. I think it has an older version of Ndless installed (that did have some issues), so I suggest you download the newest Ndless, install it on the emulator, and save the flash image.
38
« on: January 21, 2013, 11:31:36 am »
Indeed, you don't know its size and putting arbitrary size (here 256) is a bad programming behavior.
I don't want to be a nitpicker, but I have to disagree. In a practical context, using "big enough" buffers when dealing with arbitrary-sized strings is in many cases better than hassling around with a bunch of pointers and dynamically allocated memory. Using the latter method complexifies and bloats the code unnecessarily, gives the programmer additional responsibility (gotta compute the size of the data, malloc it, remember to free the memory, etc.), decreases the programs maintainability (as the code for that filename container is scattered around, when modifying bigger chunks better check it doesn't cause any undefined behavior), and generally the whatever academic perfection of the code doesn't outweigh the pain of dealing with such trivial stuff. We're not talking about security-critical government-class programs here, and it's not like there aren't any functions to avoid buffer overflows and whatnot. I'm not saying you should be using statically allocated data for everything (quite the contrary usually), but for string buffers and such, a char buf[BUF_SIZE]; is usually good enough.
39
« on: January 17, 2013, 02:54:19 pm »
 nSDL 1.1.0 Anniversary Edition is here!The 23rd of this month it will be one year since the creation of this thread and the beginning of nSDL!  Right away, here's the changelog: - Added (fastish) nSDL_GetPixel(), nSDL_SetPixel()
- Added nSDL_EnableRelativePaths()
- Added nSDL_EnableFontMonospaced()
- Fixed result from nSDL_GetStringWidth() in some special cases
- Fixed bug with stuff sometimes not showing up because of bit depth issues
- nSDL_LoadImage() now always returns a 16-bit surface
- Removed nSDL_DrawStringInRect(); very little use, complexifies code unnecessarily
- Removed nSDL_SetFontFlags()
- Changed nSDL_LoadFont() prototype to nSDL_Font *nSDL_LoadFont(int, Uint8, Uint8, Uint8)
- More accurate timer
- Cleaned up a lot of code (aka fixing what's not broken), (e.g. the font system is much simpler and easier to maintain)
- Smaller static library resulting in smaller executables
- Apart from nSDL itself, added SDL_image
- Added sample to build
As usual, the download is available on the nSDL website. For more information about the new function prototypes and whatnot, check the wiki. As mentioned earlier, this will most probably be the last update before a very long pause!
40
« on: January 12, 2013, 06:22:35 pm »
Alrighty a few things here. 1. When compiling your program, use -Wall -Wextra to spot things that could cause issues. For instance, you're freeing tempBitmap and sky but they've never been initialized. 2. Don't do stuff like this: screen->format = SDL_PIXELFORMAT_RGB332;. SDL should take care of the pixel format automatically. 3. Here's why the color was messed up: when you're using 8 bpp depth, each pixel is stored in a single byte. That byte isn't enough to store the RGB value directly, and so a palette is used to map each value to a certain color. I don't know why SDL_image would do it, but seems like the palette isn't the same on bitmap and screen (maybe you used GIMP to save it? Dunno). That's why you need to make them same, by copying bitmap's palette to screen's palette using SDL_SetColors(). Just do SDL_SetColors(screen, bitmap->format->palette->colors, 0, bitmap->format->palette->ncolors) just after loading the GIF (look up the function on google so you understand what you're writing). That way both palettes match, and here's the result:  It sucks at first but that's the way 8-bit displays work. EDIT: When I saved that GIF again on Paint, it grew to 2.1 MB, but with that one colors were correct without changing the palette at all. What program did you use to save the GIF and how'd you get it down to 800 kB? It might be the program that has a palette completely different from everyone else. 4. SDL_SetColorKey(shipSurface, SDL_SRCCOLORKEY, SDL_MapRGB(screen->format, 0xff, 0, 0xff)); should be SDL_SetColorKey(shipSurface, SDL_SRCCOLORKEY, SDL_MapRGB(shipSurface->format, 0xff, 0, 0xff));, as you're mapping that RGB(255,0,255) using shipSurface's bpp (which might very well be different from that of screen).
41
« on: January 12, 2013, 01:56:15 pm »
I quickly looked at the code.
color is taken from bitmap, which is an 8 bpp surface (the GIF, that is).
You then set color on a 16 bpp surface (the screen variable on a CX)
That must be the problem; you're drawing a 8 bpp color on a 16 bpp surface.
I suggest you to either initialize SDL with 8 bpp, or pass bitmap through SDL_DisplayFormat().
42
« on: January 11, 2013, 10:13:19 am »
Attach the whole code here, doesn't matter if it's ugly as hell. It's difficult to fix without any code. I'm pretty sure it's either your setpixel function that doesn't work, or that the color value that you're passing to the function isn't of the same bit depth as the surface on which you're drawing.
43
« on: January 11, 2013, 03:41:03 am »
Just initialize SDL with a 8bpp bit depth, i.e. in the SDL_SetVideoMode instead of is_cx?16:8, just use 8.
But quite sure the color issue is just because of some wrong SDL_PixelFormat passed to SDL_MapRGB (first parameter) or something. Your pixel access function should handle different bit depths automatically, and the only way to have strange results is by passing a wrong color.
44
« on: January 10, 2013, 07:15:43 pm »
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.
As far as example programs are concerned, that's a very good point, and there'll be included sample(s) in the next release.
45
« on: January 10, 2013, 02:00:24 pm »
SDL_DisplayFormat converts the surface to the device's native format, i.e. on a CX it'll be converted to a 16-bit surface, on others it'll be 8 bpp. I think the issue is you're passing 16-bit color to the setpixel function that draws on a 8-bit surface or something. It's difficult to guess without the code.
As for the shaders, although it might be a good idea, it isn't really part of the low-level SDL philosophy, it's too high level without much use. I want to keep nSDL fast and efficient, as a razor sharp robust base for other things, or something.
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?
Pages: 1 2 [3] 4 5 ... 22
|
Show Posts
