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

Pages: 1 ... 96 97 [98] 99 100 ... 133
1456
nSDL / Re: nSDL 1.0.2—A very fast & robust graphics library
« on: January 11, 2013, 02:48:05 am »
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?

Yeah, I can try that, but I don't know how to :/

1457
nSDL / Re: nSDL 1.0.2—A very fast & robust graphics library
« on: January 10, 2013, 01:41:01 pm »
Yeah, but what's the code you're using ? You told me to use SDL_DisplayFormat, I did so.

1458
nSDL / Re: nSDL 1.0.2—A very fast & robust graphics library
« on: January 10, 2013, 01:19:27 pm »
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 ?

Also,
Yeah, that would be a perfect candidate for tilemapping.
^ I don't understand that :/ (sorry, French inside)
The picture would be good for tilemapping because there are a lot of repeated patterns in there.

Oh okay :)

And shaders aren't part of the original SDL, but why not make ones for nSDL ? We're not restricted to functionalities already existing in the original lib (see nSDL_LoadImage and others).

1459
nSDL / Re: nSDL 1.0.2—A very fast & robust graphics library
« on: January 10, 2013, 01:11:11 pm »
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 ?

Also,
Yeah, that would be a perfect candidate for tilemapping.
^ I don't understand that :/ (sorry, French inside)

1460
nSDL / Re: nSDL 1.0.2—A very fast & robust graphics library
« on: January 10, 2013, 01:03:39 pm »
I attached the image that caused problems.

Also I think that some kind of shaders would be cool, like colour modifying or others.

1461
TI Z80 / Re: MenuKey
« on: January 10, 2013, 12:24:39 pm »
I wondered, are you using a getCSC hook or a getKey hook ? In any case, how are you testing the ON key ?

1462
The Axe Parser Project / Re: Bug Reports
« on: January 10, 2013, 12:11:32 pm »
Yeah, I got that several times too o_O

1463
TI-Nspire / Re: [C] F-Zero : trackSpire
« on: January 09, 2013, 05:25:41 pm »
To render the scene, my Mode7 engine does
Code: [Select]
setPixel(screen,x,y, getPixel(bitmap, textureX % IMG_W, textureY % IMG_H));... Plus some more calculations 14325 times. I don't think that testing 44*16 additional pixels will change anything to the speed :P (moreover, the Mode7 engine uses floats - I'll optimise it later, and the detection engine will be restricted to ints).

1464
TI-Nspire / Re: [C] F-Zero : trackSpire
« on: January 09, 2013, 05:13:46 pm »
Yeah, I think that's the best way to do this because walls can be one or a half of a tile, when the finish line, dashes, jumps and power regenerators are always a full single tile.

1465
TI-Nspire / Re: [C] F-Zero : trackSpire
« on: January 09, 2013, 05:04:41 pm »
I'll just go with pixel testing, I want to have a respectable accurance with collisions.

1466
TI-Nspire / Re: [C] F-Zero : trackSpire
« on: January 09, 2013, 12:20:14 pm »
In fact I'll go with tilemaps. The whole image can't even be entirely loaded, it's 800K in gif format but 42MB in raw format D:

So I'll recode the display engine. Updates coming soon ;)

1467
nSDL / Re: nSDL 1.0.2—A very fast & robust graphics library
« on: January 09, 2013, 01:04:57 am »
Ew, Out of Memory D: it's true that uncompressed, my gif file is 42 MB ... I'll just go with tilemapping.

1468
nSDL / Re: nSDL 1.0.2—A very fast & robust graphics library
« on: January 08, 2013, 01:20:07 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 ?

1469
TI-Nspire / Re: [C] F-Zero : trackSpire
« on: January 08, 2013, 12:53:25 pm »
Not that I can't do that, but I also want users to be able to create, load and play with their own maps, so hard-coding maps isn't a solution. But for the draw-to-a-buffer thing, I could do that but that takes even more space than a single image map (tilemap + tiles + buffer, instead of only map).

1470
TI-Nspire / Re: [C] F-Zero : trackSpire
« on: January 08, 2013, 11:00:16 am »
Quote
I can't blit a bunch of aligned images, I need to transform and blit separately each pixel of them
And precisely, for generating each pixel of the large image (pixels which you will, indeed, later transform and draw separately), you could use tilemap definitions + tile images ;)

Yeah I know that, but now that I think of it, using tiles is slower than parsing a whole map, because in addition of the initial operations that applies to a large map you'll have to find, load and apply calculations to pixels of different tiles (things that you don't have to do with a single image). Of course it saves size, but make the program slower. I think I'm better with a single image per map (that doesn't mean I can't change my mind tho, if I optimize my program to go fast enough maybe I'll have both speed and lightness).

Pages: 1 ... 96 97 [98] 99 100 ... 133