2D Engin with little problim
Author
I,m on my way to make an engin(2d) in DX7 by VB6 (so old,eh..)
After i made gif class , i could not apply colorkey modifier , the black color still exist .
please , get me a solution ASAP
You're going to have to give people some more information if you want a reasonable response. Also, just saying "get me a solution" doesn't come across as the most friendly way of asking for help.
Anyway, I presume you've been decoding a GIF format file into a DirectDrawSurface7? It's worth baring in mind that a GIF file uses lossy compression - thus the colours may not be exactly the same as the ones you think you stored. Analyzing the contents of your surface should reveal if this is (or isn't the case).
hth
Jack
Anyway, I presume you've been decoding a GIF format file into a DirectDrawSurface7? It's worth baring in mind that a GIF file uses lossy compression - thus the colours may not be exactly the same as the ones you think you stored. Analyzing the contents of your surface should reveal if this is (or isn't the case).
hth
Jack
Author
First of all ,i want to thank you jollyjeffers , but there,s some thing , about friendly asking for help ,sory about this expression because i,m non-native speaker .
Second, yes , you gotit , this is the case that i talked about .
Second, yes , you gotit , this is the case that i talked about .
I'm afraid I have too little information to help you. But I can tell you that GIF uses a loss-less compression algorithm, and is not lossy. Dunno if that helps you though... :)
ok, apologies for that.
Anyway, some more details would be a good idea. If you can post (in [ source ] ...[ /source ] tags) the relevant pieces of code that might help us help you.
Have you verified that your surface contains the data that you expect. One way to check this is to lock the surface and then loop through every pixel and do an assert() or similar on your transparent colour.
The idea with that is if you get NO debug messages then it means that your transparent colour doesn't exist - which would explain your problem. You can then try and "back track" to work out what your transparent colour actually is (probably by checking your compression/decompression routines).
hth
Jack
Anyway, some more details would be a good idea. If you can post (in [ source ] ...[ /source ] tags) the relevant pieces of code that might help us help you.
Have you verified that your surface contains the data that you expect. One way to check this is to lock the surface and then loop through every pixel and do an assert() or similar on your transparent colour.
The idea with that is if you get NO debug messages then it means that your transparent colour doesn't exist - which would explain your problem. You can then try and "back track" to work out what your transparent colour actually is (probably by checking your compression/decompression routines).
hth
Jack
Quote:Original post by skanatic
But I can tell you that GIF uses a loss-less compression algorithm, and is not lossy.
Unless I've been missing something really big, GIF is a lossy compression scheme. It does a K-Means/analysis and picks a palette of 256 (24bit) colours and encodes the image as that. Thus the image you load will have no more than 256 colours.
I suppose, if your original images used less than 256 colours you could get away without it being lossless - but thats unlikely [smile]
hth
Jack
Quote:Original post by jollyjeffers
Unless I've been missing something really big, GIF is a lossy compression scheme. It does a K-Means/analysis and picks a palette of 256 (24bit) colours and encodes the image as that. Thus the image you load will have no more than 256 colours.
I suppose, if your original images used less than 256 colours you could get away without it being lossless - but thats unlikely [smile]
That's not the definition of a loss less compression though. JPG on the other hand is lossy.
http://en.wikipedia.org/wiki/Lossless_data_compression
EDIT:
Saving a 24bit image in a GIF is just sad... :) PNG would be a better choice.
Author
To illuminate the misty , here is the problim :
EDIT: Using source tags makes it more readable...
Function StartLoad(filename As String, X As Integer, Y As Integer) As BooleanSizeX = XSizeY = YIf TDN = "" Then MsgBox "1": Exit FunctionIf TFN = "" Then MsgBox "2": Exit FunctionIf FN = "" Then MsgBox "3": Exit FunctionDim Buffer$, Head$Dim LastIn As Long, NextIn As LongDim Comma$Dim CurPic As String, Lenth As LongDim fHead As StringComma = Chr(0) & Chr(33) & Chr(249)Open filename For Binary As #1Lenth = LOF(1)If Lenth < 128 ThenClose #1Exit Function: MsgBox "5"End IfBuffer = String$(Lenth, Chr(0))Get #1, , BufferClose #1LastIn = InStr(1, Buffer, Comma) + 1If LastIn = 1 Then Exit FunctionHead = Left(Buffer, LastIn)LastIn = LastIn + 2Dim F As IntegerF = -1DoF = F + 1DoEventsNextIn = InStr(LastIn, Buffer, Comma) + 3If NextIn = 3 Then NextIn = LenthCurPic = Head & Mid(Buffer, LastIn - 1, NextIn - LastIn)Open filename For Binary As #1Put #1, 1, CurPicClose #1Set Pic(F) = LoadPicturefile(filename, X, Y)Kill filenamefHead = Left(Mid(Buffer, LastIn - 1, NextIn - LastIn), 16)fTime(F) = (Asc(Mid(fHead, 4, 1)) + Asc(Mid(fHead, 5, 1)) * 256&) * 10&If NextIn = Lenth Then Exit DoLastIn = NextInLoopCurFrame = 0If fTime(0) <> 0 ThenEnd IfNumFrames = FStartLoad = TrueEnd FunctionEDIT: Using source tags makes it more readable...
Quote:Original post by skanaticQuote:Original post by jollyjeffers
Unless I've been missing something really big, GIF is a lossy compression scheme. It does a K-Means/analysis and picks a palette of 256 (24bit) colours and encodes the image as that. Thus the image you load will have no more than 256 colours.
I suppose, if your original images used less than 256 colours you could get away without it being lossless - but thats unlikely [smile]
That's not the definition of a loss less compression though. JPG on the other hand is lossy.
http://en.wikipedia.org/wiki/Lossless_data_compression
EDIT:
Saving a 24bit image in a GIF is just sad... :) PNG would be a better choice.
Ah, okay then - I see your point.
Although, pretty much every usage I've seen of GIF tends to mutilate "true colour" photos down to a 256-colour quantized representation. I'd personally term that as lossless as the compression algorithm discards (loses) data [smile]
In the context of this thread, it is possible that the compression doesn't store the transparent colour as the same colour code as expected. Which is why I brought up the possibility. Doing these sorts of operations after an image has been churned up in a compression algorithm is a good way of introducing errors unless you're very sure you know whats going on.
Jack
High Volt, you should try and post the code that would actually help.
The code for function LoadPicturefile(filename, X, Y) for example. And the part where you are actually setting the colour key. And for good measure, the render loop as well. Otherwise you would be waiting till eternity for a solution to your problem!
OOT: I see that jj has taken over as the moderator for DirectX. I've been away at the openGL thread for the past few months you see (cries of "heretic!")... Anyway, congrats jack! Wonder what Muhammad is upto now...
The code for function LoadPicturefile(filename, X, Y) for example. And the part where you are actually setting the colour key. And for good measure, the render loop as well. Otherwise you would be waiting till eternity for a solution to your problem!
OOT: I see that jj has taken over as the moderator for DirectX. I've been away at the openGL thread for the past few months you see (cries of "heretic!")... Anyway, congrats jack! Wonder what Muhammad is upto now...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
