| |
| |
| |
|
Comments:
<0> heya
<0> any quick way to do clipping when I'm drawing stuff directly to a surface's pixel data?
<1> yuriks: Depends what "fast" is.
<1> And clipping should be done prior to drawing.
<0> right now I'm testing each pixel on the screen if it's out bounds
<0> Madsy: how?
<1> http://www.google.com/search?hl=en&q=sutherland+hodgman
<0> I want to just avoid blitting outside the surface
<1> http://en.wikipedia.org/wiki/Sutherland-Hodgman
<1> What are you drawing? Rectangles? Lines? Squares? Triangles? Points?
<0> http://yuriks.nonlogic.org/starcroll.tar.bz2 < my code, acoording to my profiler blit_star is 60% of the code! =O
<1> http://www.rafb.net/paste
<1> Next time you state a question, get some reasonable info with it.
<1> We are not psychic or mindreaders you know.
<0> http://rafb.net/p/HNKt2V86.html
<0> I'm drawing star_spr
<0> 9 is transparent, 1 is a pallete multiplier
<0> 1, 2 and 3 are pallete multipliers
<1> blit star is full of evil lookups and 2D arrays
<1> And a lot of calculations could be moved to outside the nested loops.
<0> "evil lookups"?
<1> For instance, calculating (yy+y)*(screen_surf->w) for every x is just stupid.
<1> I ***ume you magic number 9 works as an alpha mask?
<0> more like a colorkey, but, yeah
<1> Use alpha blending instead.
<2> 'xx+x >= 0 && xx+x < 320' == '(unsigned int)(xx+x) < 320'
<1> For totally invisible objects, SDL does this faster.
<1> Branching inside a double nested loop. Mmmm..
<0> =P
<0> you mean me to use SDL_Blit and friends?
<1> Looks to me that you are drawing squares anyway.
<1> So yes.
<1> It also does clipping for you.
<0> but how am I going to do the color shifting?
<0> that file compiles by itself, try it
<1> Perhaps another time :)
<1> I'm going to bed in a moment.
<0> I'm cycling the color of reach star based on the Z value, by offsetting the pallete index
<0> I don't see any way to make SDL_Blit do that for me
<1> Can't you change the palette before drawing?
<1> I don't know the speed penalty for doing that, but.
<0> hmm, no
<0> let me show you a screenshot
<0> http://yuriks.dyndns.org:9090/~yuriks/stars.png
<1> I can help you more tomorrow night. I'm home at 09:00 PM
<1> But my advice so far is that your setup is okay. Just optimize your inner loops.
<0> the pallete consist of a color spectrum of 64 colors, once with full brigthness, then at 50%, then at 25% (corresponding to the 1, 2 and 3 on the array)
<0> hmm, ok
<0> thanks
<1> And do the clipping outside the loop.
<1> Clipping when drawing has never been a good idea.
<1> I gave you a bunch of urls to info regarding clipping.
<1> Good night
<0> the wikipedia link just redirects to clipping =P
<0> and it looks like it has to do with polygons, but, ok
<1> Well, isn't a square a polygon?
<1> Not only that; squares are convex.
<0> well, I dunno, I think I'll try to come up with a simple calculation of my own
<1> Clipping squares is simple
<1> All you need is the border coordinates and the min,max values of the square
<3> hey, its normal to everytime i run a program made in SDL to create the sdlerr? But when i close the app the stderr is automatically deleted only stdout is left
<3> by the way the stderr is empyt
<4> That's the behaviour right, the files are removed if they end up empty.
<4> One could argue that only creating the file once it is needed instead would make more sense, but, well, you know.
<5> I'll argue that it's better not to use Windows.
<3> Ok thanks, i was worried cause of stderr but seems everything is going ok :)
<6> Hello :)
<7> is it true that you are not allowed to call any SDL api calls while your surface is locked?
<8> yes, because the surface might be a DirectDraw surface, and subject to the same rules
<7> I have a SDL_Surface stored in a cl***. This surface gets written to every frame. After the first iteration, the surface is ok. But on the next loop iteration, the surface data is corrupted...
<7> and when i comment out some code, its fine
<7> here is the code: http://rafb.net/p/iE4tHl26.html
<7> the private variable Slider::surf gets corrupted
<7> i.e. contains junk data on the second iteration
<9> Are there any good C++ SDL Tutorials for absolute beginner game programmers?
<10> Yeah, a few.
<10> http://lazyfoo.net/SDL_tutorials/index.php
<10> that one is pretty good not too bad
<10> Teaches quite a few essentials
<10> wikipedia has a couple
<10> http://gpwiki.org/index.php/C:SDL_tutorials
<10> both are good
<11> QMario: this might be useful for you http://gpwiki.org/index.php/SDL
<12> Hello
<12> Can anyone say me some SDL app/game that uses full screen and being 2D?
<12> I think found some incompatibility with my configuration/system and SDL
<13> check the games database ... most 2d ones probably offer fullscreen
<14> anyone got a sdl_mixer.lib in OMF format?
<14> (for Win32)
<15> I have some pthreaded coded and I want each thread to write to the screen. Is SDL threadsafe in this regard?
<16> first, SDL has cross-platform thread wrapper
<16> second, NEVER use graphic calls from more than one thread
<15> Let's say I have one SDL_surface per thread. After each thread joins I call blit to move my SDL_surfaces onto the screen. How does that sound?
<16> if you draw into the screen from both, you're in trouble
<16> however if you do that thing you said, it may work
<16> as long as it's always the same thread the one that blits surfaces into screen
<15> That I can do. It's a bit more awkwards, but manageable
<15> I'm doing pixel access in each thread anyway so writing to a memory surface firist and then perfroming a blit is probably a good idea
<15> here's an interesting link. Looks like SDL was threadsafe for some surfaces years ago http://lists.libsdl.org/pipermail/sdl-libsdl.org/1999-April/002027.html
<17> Hello .. is there anyway to determine at run time if a surface is locked? thank you
<16> It should be noted, that since SDL 1.1.8 surface locks are recursive. This means that you can lock a surface multiple times, but each lock must have a match unlock.
<16> quote from docs
<16> so if you need pixel access, lock it first, even if it was locked before; but both should have an unlock
<16> http://docs.mandragor.org/files/Common_libs_documentation/SDL/SDL_Documentation_project_en/sdllocksurface.html
<17> PovAddict: Thanks for the answer ... so there isn't really a way to know for sure
<16> no there is no SDL_IsSurfaceLocked :)
<16> why do you need it?
<4> Cupu: You can cheat a bit, the SDL_Surface struct has a member 'locked', which is non-zero if the surface is locked.
<17> PovAddict: mostly just for the sake of argument
<16> not public though
<4> Don't completely count on it never changing, but it should be relatively safe.
<17> tesmako: Thank you .. that would work just great
<18> :/quit
Return to
#sdl
or
Go to some related
logs:
#fedora
pylint undefined '_'
nvidia api differences ubuntu
#sendmail
module via not found
CPC6600 buy
playing h264 on linux performance
#python
#gaim
#lisp
|
|
