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 ... 21
31
« 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! 
32
« 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().
33
« 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.
34
« 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.
35
« 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.
36
« 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?
37
« on: January 10, 2013, 01:40:28 pm »
I have no issues, I get this while blitting the image: (don't mind the fish)  You do understand the surface IMG_Load returns is 8bpp as the GIF is 8bpp?
38
« on: January 09, 2013, 05:43:54 pm »
I'll just go with pixel testing, I want to have a respectable accurance with collisions.
I'm not sure if that's a good idea, as pixel operations are never (on any platform) very fast
Except in some cases on the 83+ (in Axe and TI-BASIC). In TI-BASIC there isn't much difference over using matrices, but in Axe if you need accuracy it's the fastest way.
Yes, but when you have a massive 96x64 resolution...
39
« on: January 09, 2013, 05:15:28 pm »
I'll just go with pixel testing, I want to have a respectable accurance with collisions.
I'm not sure if that's a good idea, as pixel operations are never (on any platform) very fast; it could give quite a blow to performance. But what do I know, doing mode7 already involves a lot of per-pixel stuff and it doesn't seem to be that slow.
40
« on: January 09, 2013, 12:59:34 pm »
I think I'm doing something wrong, because SDL_GetTicks always returns 0. Are you sure about that? Did you try printing out the value it returns? I just tried it on the emulator and seems to be working.
Yes, I used uart_printf and it displayed 0. Anyways, I figured out how to read the timer value directly, and that works fine. However, the frame time to floats isn't working for some reason. I used:
float floatFrameTime = (float)(time - oldTime);
uart_printf("\n%u %f", time - oldTime, floatFrameTime);time-oldTime displays correctly, but floatFrameTime always prints 0.00.
Yeah that's because of a bug or some issue with printing floats. The nspire syscalls for some reason can't handle printing floats. Try casting it to an integer. Also remember the value returned by SDL_GetTicks() is a Uint32. EDIT: BTW, to get the timer value, did you read the RTC or the millisecond timer?
41
« on: January 09, 2013, 12:29:00 pm »
I think I'm doing something wrong, because SDL_GetTicks always returns 0. Are you sure about that? Did you try printing out the value it returns? I just tried it on the emulator and seems to be working.
42
« on: January 09, 2013, 11:19:43 am »
If you're using... *cough* *cough* nSDL, there is SDL_GetTicks().
43
« on: January 09, 2013, 06:32:06 am »
Did you fix the color issue or not? Could you attach the file that caused problems here?
44
« on: January 08, 2013, 01:47:26 pm »
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 ?
Dunno, I just saved the file as a GIF on Paint. Can you post the file here? EDIT: Try if passing the surface through SDL_DisplayFormat() and see if it helps. BTW, for a speed boost you should always pass your files' surfaces through that function, it avoids SDL having to convert to the display format on the fly.
45
« on: January 08, 2013, 11:13:13 am »
Alrighty, but what does it have to do with this?
Pages: 1 2 [3] 4 5 ... 21
|
Show Posts