Ready4Dis

Members
  • Content count

    1238
  • Joined

  • Last visited

Community Reputation

180 Neutral

About Ready4Dis

  • Rank
    Contributor
  1. Why not add some sort of animation support into the render, along with support for timing. This way, your script could say, animate this sprite using this animation sequence for this amount of time, or until I tell you to stop. That way, the rendering core can do the animation and not worry about what the script is doing. If you add in a timer, it can animate it at a specific interval even if it doesn't hear back from the script. And the script doesn't need to update the renderer every frame, just needs to notify something started/stopped, etc.
  2. Yeah, command line options is the normal way... int main(int argc, char *argv[]) { int ctr; for (ctr=0;ctr!=argc;++ctr) printf("%d %s\n", ctr, argv[ctr]); return 0; } If you've ever seen that, then you have what you need... argc stores the argument count, argv is an array of points to strings (arguments). Have fun :)
  3. Quote:Original post by swiftcoder The bigger issue I was hinting at, which you seem to have missed, is that nobody in this thread actually suggested Boost - let alone that you should rewrite your code to use boost::phoenix. Really... nobody suggested boost in this thread? Have you read the thread? Quote:Original post by megamoscha Anyway @OP you should really consider to take a look at boost. Quote:Original post by Codeka Actually, I'd recommend changing it to boost::function<void ()> - it's more readable (in my opinion) and it's more flexible, too! Hmm... looks like you haven't. Anyways, I agree, boost in this case just adds confusion, requires learning a new library, will add size and compile time to his project, all for no gain. Not saying boost doesn't have it's place in code, just saying not in all code. Anyways, OP has gotten it working and has moved on. On the contrary, I recommend the OP learn boost at some point, just not for this.
  4. Quote:Original post by spinningcube Quote:Original post by Ready4Dis See, you are thinking there is a pre-defined background color. He is talking about rendering an image KEEPING the alpha information and being able to blend it over top of ANY background, so there is no pre-determined color to blend. So you must use the alpha information as my equation does, and treat it as a 100% invisible background (aka, a completely transparent background), so there is no final blend color UNTIL you apply the background :). So you must store the alpha info along with color information without a background blend, so blending 2 sources together that can be blended against any background color was his issue, which is now solved. Next issue is getting AA (Anti Aliasing) working, based on the same restrictions as above. I believe this is the solution... haven't tested it much, so let me know if you find any problems with it. Col1.a /= 4; Col2.a /= 4; Col3.a /= 4; Col4.a /= 4; Dst1 = Col1*Col1.a; Dst2 = Col2*Col2.a; Dst3 = Col3*Col3.a; Dst4 = Col4*Col4.a; DstAlpha = Col1.a + Col2.a + Col3.a + Col4.a; DstCol = Dst1 + Dst2 + Dst3 + Dst4; Ok fair enough. If it's solved then it's cool :-) For the aa averaging the alphas seems wise. I don't do aa like that in fact. I just make a higher resolution image and downsample. Brute force for the win I guess :-) Pablo www.visualbiotech.ch Yes, he is basically down sampling, however you can't just blend the colors together, because they aren't 'final' colors yet (there was no background applied), so simply blending the colors directly will not work. I am not positive this AA formula is correct, but seems to give ok results. --- Edit --- Thinking about it some more, I know my AA formula is not correct, I will keep working on it, let me know if you find something else in the mean time. [Edited by - Ready4Dis on June 18, 2009 4:14:22 AM]
  5. Quote:Original post by spinningcube Quote:Original post by garma83 Quote:This is my interpretation and not an attack on you. No problem. No offense pablo, but all of this has been explained before. That was my point. Quote: You always have to start with some background color such as blue, white, grey, black or what have you. That is exactly the problem. You say you always have to start with some background color. In my case, the background color can be fully or partially transparent. That is NOT the same as NO background. That completely changes the issue. Now I am 100 percent confused. How does the tranparency of a surface that is behind the fragment have anything to do with the final color? Only the surface in front of it is important, no? Because the background color or starting color is already decided. If you say the transparency of the previous surface such as a background has an effect on the color contribution of the next one then it's a different beast altogether. In our ray tracer we just add the color contribution of the last fragment. There is no such thing as forward contribution. Only the last painted fragment decides how much it is added to the color. Just as in a vanilla GL_BLEND operation with alpha channels. If there is a dark background we get the expected result of a darker surface. Pablo See, you are thinking there is a pre-defined background color. He is talking about rendering an image KEEPING the alpha information and being able to blend it over top of ANY background, so there is no pre-determined color to blend. So you must use the alpha information as my equation does, and treat it as a 100% invisible background (aka, a completely transparent background), so there is no final blend color UNTIL you apply the background :). So you must store the alpha info along with color information without a background blend, so blending 2 sources together that can be blended against any background color was his issue, which is now solved. Next issue is getting AA (Anti Aliasing) working, based on the same restrictions as above. I believe this is the solution... haven't tested it much, so let me know if you find any problems with it. Col1.a /= 4; Col2.a /= 4; Col3.a /= 4; Col4.a /= 4; Dst1 = Col1*Col1.a; Dst2 = Col2*Col2.a; Dst3 = Col3*Col3.a; Dst4 = Col4*Col4.a; DstAlpha = Col1.a + Col2.a + Col3.a + Col4.a; DstCol = Dst1 + Dst2 + Dst3 + Dst4;
  6. Meh, it's much more fun coming up with solutions than just searching online for it ;). I see what you're saying about anti-aliasing... they need to be equal parts. I will see what I can come up with, lol. I am thinking something like .25,.25,.25,.25 should be the solution to your problem (3x 0,0,0,0, and 1x 1,1,1,1). So, I will start thinking about it some today and see what I can come up with. Glad my formula works perfectly for you, send me some screen shots when you get it working good :). I will see what I can come up with for your anti-aliasing problem, they all need to be treated equally, but their color can only modify based on their alpha.
  7. My DstCol.a value is correct in my formula. Our formula's are similar but not exact (mine assumes all values are 0->1 floating point). Try out mine, it gives correct color and alpha results. For example, if you use 0,0,0,.5 and 1,1,1,.5, they would combine as such: .25,.25,.25,.75 If you passed 1,1,1,.5 THEN 0,0,0,.5, it would combine as such: .75,.75,.75,.75. So, the order of transparency makes a big difference (which is correct). The returned alpha value (in DstCol) is correct, if you have something that is 50% translucent, and another behind it, then 50% of what was remaining is considered (so, 50% of 50% = 25%). What values are you expecting for alpha that you say are incorrect? If the first color is 50%, then the second is 50% alpha, that should be 75% total... 50% for the first, then 50% of the leftover 50% (25%) for the second, which totals 75% opacity, (or 25% translucency leftover). After looking and playing with a few numbers, my formula should work correctly in all cases as expected, I will play around with it some more later (make a spreadsheet up with both formula's and compare results and see which one is 'more' correct). My formula also only uses a single intermediate variable (as long as they start as float's)
  8. After thinking about it some more, my formula is incorrect... this one works much better Alpha2 = (1-Col1.a)*Col2.a; //How much do we have left? DstCol.a = Col1.a + Alpha2; DstCol.r = (Col1.r*Col1.a + Col2.r*Alpha2)/DstCol.a; DstCol.g = (Col1.g*Col1.a + Col2.g*Alpha2)/DstCol.a; DstCol.b = (Col1.b*Col1.a + Col2.b*Alpha2)/DstCol.a; This works how you think it should (or at least how I think it should). First it calculates the percentage each color value effects the final color, then calculates the final alpha value. So, if there is already .5 (1/2 opacity), there is only .5 translucency left that it could possibly effect. It works for all values, where the first one would end up with values > 1 in certain cases. This formula insures no values > 1 (unless values >1 are inputed), and will tend towards full opacity until a value of either 1 is input (in either col1 or col2). Hope this helps, let me know how the results look, I haven't done any testing with it except in my head :). *** Edit *** Made it more correct... again :P. [Edited by - Ready4Dis on June 12, 2009 7:13:53 AM]
  9. Ok, I think I have it: DstCol.a = sqrt(Col1.a*Col1.a+Col2.a*Col2.a); DstCol.r = (Col1.r*Col1.a + Col2.r*Col2.a)/DstCol.a; DstCol.g = (Col1.g*Col1.a + Col2.g*Col2.a)/DstCol.a; DstCol.b = (Col1.b*Col1.a + Col2.b*Col2.a)/DstCol.a; There you are ;). You can apply as many times as you find objects in it's path. Should work as you expect... let me know. *** Edit *** See next response, it has my corrections, this is incorrect!!!! [Edited by - Ready4Dis on June 10, 2009 3:39:50 PM]
  10. You're way over thinking this... Simply return .5, 1,1,1. Then, whatever application displays the rendered image is responsible for blending it with IT's background color, since you have no background color, it doesn't make a change at all, so you do nothing with the 0,0,0,0. You aren't taking into account DestAlpha, you are only calculating using SrcAlpha. I will try to work out a formula for this today if you'd like. I came up with a few samples and what the results *should* be, just need to find an equation to fit: (r,g,b,a) 1,1,1,0.5 0,0,0,0 Result = 1,1,1,0.5 1,1,1,.5 0,0,0,.5 Result = .5,.5,.5,0.75 1,1,1,.75 0,0,0,.25 Result = .75, .75, .75, 0.8125 1,0,0,.5 0,1,1,.5 Result = .5,.5,.5,0.75 I will try to get back later (after work) and try to get you a formula if you can't figure something out.
  11. Yes, once it's uploaded to the GPU, you can delete your copy. The GPU has it's own memory manager/organizer that will put it where it needs it (either GPU memory, or main memory), but it will create/store it's own copy, so once you load it, delete it and stop wasting memory ;).
  12. Sounds good, get me some information, and I can start working on it. C/C++ good? I use microsoft visual studios for the most part. Do you have any documentation on your plugin interface? I can start working on it whenever, I can do perspective correct texture mapping, and whatever bit-depth you want, let me know :). --- edit --- Looked at the program a bit, need to get some more time with it to see, but looks pretty simplistic so far. You'll have to let me know how the plugins for rendering work, and I'll get started and keep you updated. Or I'll just write one that is pretty easily extended with a short standalone to show you how it works.
  13. I could make something pretty easily to support what you're looking for. I don't have any recommendations, but I can write a software renderer pretty quickly (although not super optimized if you want it quickly), but if you let me know what you need (lighting, vertex, textures, bits per channel, how many channels, r,g,b (3), r,g,b,a (4), ?). If you're interested, I'm not looking for any pay, just something to do/play with :). I have written them in the past, most of my old tricks probably aren't as useful today (fixed point maths, etc due to lack of FPU on 386/early 486). Also, what kind of perspective transforms does it have to be able to handle? Are you using any camera controls from opengl that will have to be emulated as well? Viewport settings, etc?
  14. Why are you subtracing a time delta? Why not just store the time and compare them directly? Then you simply loop through the most current line until the oldest line, once you hit a line that is to old, simply remove it from the list or mark it as invisible or whatever you want, you need only loop until the time delta is greater than the fade time. for (Ctr = LineList.GetSize()-1; Ctr!=0; --Ctr) { TimeDelta = CurrentTime - LineList[Ctr].PostTime; if (TimeDelta > MaxDelta) break; //No need to continue any further up //This generates a number between 0 and 1, 1 being solid, 0 being faded out LineList[Ctr].FadePercent = 1.0f - (TimeDelta / MaxDelta); } Pretty simple really, otherwise you are subtracting and going through an entire loop for no reason, then you still need to figure out something to do with your values. It breaks out once it hits the first line that is to old, no need to go any further.
  15. Quote:Original post by XTAL256 Quote:Original post by Saruman some people use this-> before member variables in order to avoid code warts. (i.e. instead of naming member variables something like: m_myVariable they will use this->myVariable) Yeah, that's what i do. I sometimes do this in constructors (yes, i know i should use the : thing) : Something(int var) { this->var = var; } I was going through some of my code the other day and i wondered why i was putting all these "this->"'s so i removed them all. It was only after my program crashed that i realised why i used them in the first place (because otherwise it was just doing var = var). It may not be the best habit but i just hate prefixing all member variables with "m_". It's redundant and just plain silly. Quote: From How To Write Unmaintainable Code a naming convention from the world of C++ is the use of "m_" in front of members. This is supposed to help you tell them apart from methods, so long as you forget that "method" also starts with the letter "m". :) This sounds rediculous... you say that prefixing m_ is redundant and plain silly, yet you prefix this-> to all your member varaibles... how is that any less redundant (it is more, since it's more typing), and just as silly. It is just an indicator saying that it's part of the class, no matter which way you prefer, I don't see how you can see one as redundant and not that other. You even admit that seeing this-> everywhere in your code was distracting so you tried to remove them, and it failed miserably... had all your member functions been prefixed with m_ instead, you wouldn't have thought twice about why it was there. It sounds very hypocritical to call one way of prefixing redundant, and not consider the other the same (they are BOTH redundant, however they will BOTH clarify what you're trying to do, so neither is 'silly'). As you've found out, using this-> confused yourself at a later date, just imagine someone else trying to work on your code seeing this->var = var; all over. m_var = var; is a lot cleaner looking, and gets the same point across, and nobody will try to strip out all the m_ like they may be tempted to with the this-> prefix.