|
ultra-inquisitor posted:If you're manually calculating the points using Bresenham, just draw the "pixels" as quads? Thank you! You've been a huge help, but I seem to be misunderstanding OpenGL, or Bresenham, or both. Whenever I run this, no matter what I put in for x1,x2,yc1,y2 (yc1 was named as such because Visual Studio complained when I had a variable named y1), it always results in the same thing: the big pixels being drawn from the very bottom left of the window to the very top right. I tried integrating the optimized algorithm from Wikipedia since I want the code to be robust, but it does betray my understanding of the algorithm a little bit. http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm#Optimization code:
|
# ? Feb 13, 2010 02:37 |
|
|
# ? Jun 1, 2024 21:10 |
|
I haven't checked your Bresenham code, but OpenGL does indeed consider bottom left to be the origin, not top left as is usual.
|
# ? Feb 13, 2010 11:02 |
|
ultra-inquisitor posted:I haven't checked your Bresenham code, but OpenGL does indeed consider bottom left to be the origin, not top left as is usual. Depends on how you set up your projection matrix, it's entirely possible to have the top left be the origin and +Y to be down. Whether that's a good idea is another matter, but it's not difficult.
|
# ? Feb 13, 2010 18:01 |
|
I'm statically compiling in a separate malloc which does weird things with dynamically linked functions like strdup that call their own malloc from the library. I know that I can do invasive things like changing LD_PRELOAD to cause strdup to use a different malloc. Is there anything less invasive I can do to cause strdup to rely on my statically linked malloc? Currently I'm just using my own implementation of strdup. In the future I imagine I will encounter situations where I won't be able to use that method.
|
# ? Feb 13, 2010 18:11 |
|
functional posted:I'm statically compiling in a separate malloc which does weird things with dynamically linked functions like strdup that call their own malloc from the library. I know that I can do invasive things like changing LD_PRELOAD to cause strdup to use a different malloc. Is there anything less invasive I can do to cause strdup to rely on my statically linked malloc? Currently I'm just using my own implementation of strdup. In the future I imagine I will encounter situations where I won't be able to use that method. ELF? It should do it by default, actually, unless you played with visibility (and unless strdup calls a symbol other than malloc). Which is why it's so dangerous to mess with these.
|
# ? Feb 13, 2010 18:21 |
|
OddObserver posted:ELF? It should do it by default, actually, unless you played with visibility (and unless strdup calls a symbol other than malloc). Which is why it's so dangerous to I don't understand your post. I am working on a UNIX-compatible system and compiling with gcc. The call free(strdup(str)) always fails contrary to the manual specification. Since I have implemented my own malloc and free this indicates to me that strdup is calling some other malloc. Can you explain what you mean?
|
# ? Feb 13, 2010 22:59 |
|
functional posted:I don't understand your post. I am working on a UNIX-compatible system and compiling with gcc. The call free(strdup(str)) always fails contrary to the manual specification. Since I have implemented my own malloc and free this indicates to me that strdup is calling some other malloc. Can you explain what you mean? What system in particular? I mean that normally ELF symbols are global, so there is only a single malloc symbol for the whole program unless you specially try to avoid it. That means that if strdup calls malloc it should call your malloc --- but it might also be calling some sort of __system_malloc or whatever (or the inside-libc calls might be optimized to go directly to the default malloc implementation). There in lies the danger since you could potentially end up with library calling a mixture of the two heap managers. At any rate, on my Linux machine code:
|
# ? Feb 13, 2010 23:10 |
|
functional posted:I'm statically compiling in a separate malloc which does weird things with dynamically linked functions like strdup that call their own malloc from the library. I know that I can do invasive things like changing LD_PRELOAD to cause strdup to use a different malloc. Is there anything less invasive I can do to cause strdup to rely on my statically linked malloc? Currently I'm just using my own implementation of strdup. In the future I imagine I will encounter situations where I won't be able to use that method. Depending on what you are trying to do, you might be able to get away with the --wrap option to ld. With this you can intercept malloc calls without having to do your own heap management. ld man page posted:--wrap=symbol
|
# ? Feb 14, 2010 00:52 |
|
ultra-inquisitor posted:I haven't checked your Bresenham code, but OpenGL does indeed consider bottom left to be the origin, not top left as is usual. It does that no matter what coordinates I put in there - always bottom left to top right, when I just want it to draw a line segment. How do I get it to draw in the specified locations?
|
# ? Feb 14, 2010 20:01 |
|
Whilst farting I posted:It does that no matter what coordinates I put in there - always bottom left to top right, when I just want it to draw a line segment. How do I get it to draw in the specified locations?
|
# ? Feb 15, 2010 17:35 |
|
ultra-inquisitor posted:Looking back at your code, it looks like you are implementing the algorithm wrong. For one thing, much of the code only has to be done once - at the start - but you are doing it for each iteration. Thus variables like errorCheck are being reset when they probably shouldn't be. For some reason, if I don't have the while at the beginning, it only draws the very first pixel. However, I have gotten it working except for drawing straight up or down vertically. How would I accommodate for that? I have a feeling that's the errorCheck variable getting continually reset but I don't know why I'm having trouble with the while loop. code:
|
# ? Feb 15, 2010 22:54 |
|
I decided to make my first GUI program in C++, more to get a handle on the basics of GUI programming than any utilitarian purpose. I decided to go with Qt for this, and I've pretty much got it finished now, but I can't seem to figure out how to compile it so that all dependencies are contained within the .exe to make it portable, instead of having to drop all its dependant DLLs in the executable folder. I tried to follow Qt's guide, but there was an error while mingw32-make was doing its thing, which ended up totally loving up the Qt library, so I couldn't compile any programs at all. This is the error: code:
code:
Cosmopolitan fucked around with this message at 01:00 on Feb 16, 2010 |
# ? Feb 16, 2010 00:38 |
|
Why are you naming the parameters and then trying to outsmart the compiler to tell it you're not using them? (Also I can just about guarantee that that's not what is segfaulting.)
|
# ? Feb 16, 2010 01:43 |
|
Avenging Dentist posted:Why are you naming the parameters and then trying to outsmart the compiler to tell it you're not using them? I don't really know what you're talking about, the only steps I took involved copypasting the commands in that Qt guide ("configure -static", and "mingw32-make"). All I know about what's going wrong is I went to the file and line specified, and that's what I pointed out with "<---- Here". I don't know what that file/function is or what it does. Cosmopolitan fucked around with this message at 01:55 on Feb 16, 2010 |
# ? Feb 16, 2010 01:49 |
|
Is there an easier way to write this? if (times_i_went_to_the_store == 3 || times_i_went_to_the_store == 5) { do whatever; } Is there a way to do: if (times_i_went_to_the_store == 3 or 5) { do whatever; }
|
# ? Feb 16, 2010 04:40 |
|
Schweinhund posted:Is there an easier way to write this? code:
|
# ? Feb 16, 2010 04:46 |
|
edit: Wait a minute my terrible goonsay joke wasn't even right dammit.
The1ManMoshPit fucked around with this message at 05:13 on Feb 16, 2010 |
# ? Feb 16, 2010 05:07 |
|
code:
|
# ? Feb 16, 2010 06:26 |
|
I did a mingw32-make confclean and reconfigured it with more options, namely -debug-and-release and -fast, and after a couple of hours of compiling, it gives me another error:code:
|
# ? Feb 16, 2010 06:56 |
|
Anunnaki posted:This is getting really frustrating. The compiler is crashing. I'd suggest checking for updates, as well as running a memory test and making sure your machine isn't overheating. Edit: also, independent of that, if you have decent broadband you could just grab binaries for Qt-on-mingw -- no need to build the library yourself: http://qt.nokia.com/downloads/sdk-windows-cpp OddObserver fucked around with this message at 07:14 on Feb 16, 2010 |
# ? Feb 16, 2010 07:11 |
|
OddObserver posted:The compiler is crashing. I'd suggest checking for updates, as well as running a memory test and making sure your machine isn't overheating. Everything's up-to-date, and I don't think I'm having heat issues; my CPU never goes above 50 C and I game regularly, and have had no BSODs or any instability. The Qt installer installs the shared library, and I haven't been able to find a prebuilt static Qt library.
|
# ? Feb 16, 2010 08:18 |
|
code:
|
# ? Feb 16, 2010 08:28 |
|
Anunnaki posted:The Qt installer installs the shared library, and I haven't been able to find a prebuilt static Qt library.
|
# ? Feb 16, 2010 13:52 |
|
Schweinhund posted:Is there an easier way to write this? From a post I made in the Coding Horrors thread a while back. Paste this into, I dunno, "membership.h": code:
code:
|
# ? Feb 16, 2010 14:27 |
|
edit: nvm
Mr.Mojo fucked around with this message at 14:44 on Feb 16, 2010 |
# ? Feb 16, 2010 14:40 |
|
Whilst farting I posted:For some reason, if I don't have the while at the beginning, it only draws the very first pixel. However, I have gotten it working except for drawing straight up or down vertically. How would I accommodate for that? I have a feeling that's the errorCheck variable getting continually reset but I don't know why I'm having trouble with the while loop.
|
# ? Feb 16, 2010 15:18 |
|
Anunnaki posted:mingw32-make mingw is a poor choice for static linking (and every other situation in which you aren't forced to use it). Use msvc instead.
|
# ? Feb 16, 2010 18:14 |
|
What? There's nothing wrong with MinGW (except that it uses GCC, but when you're comparing that to MSVC, it's basically a wash).
|
# ? Feb 16, 2010 18:43 |
|
Schweinhund posted:Is there an easier way to write this? code:
|
# ? Feb 16, 2010 19:32 |
|
Mustach posted:Are you being forced to distribute this as a "standalone" executable? If not, just link dynamically because nobody worth giving it to is going to cry if you give them a zip file or an installer instead of a huge-rear end exe. Well, just having to distribute the DLLs with the .exe really isn't the problem so much as keeping track of which ones I need to distribute with it. When I tried sending my friend the .exe, I copied all the DLLs in the release folder, but he got an error about another missing DLL, which I had to find and send to him for it to work. Also, genuine question, what's wrong with GCC, compared to MSVC? The free version of Qt only comes with MinGW, so I'm stuck with that in any case.
|
# ? Feb 16, 2010 21:10 |
|
As I posted in the Coding Horrors thread a while ago~Vanadium posted:I got pretty much as far, except I did the recursion by composition and not inheritance, but then I tried to wrap boost::call_traits<T>::param_type around everything to avoid needless copying and it all fell apart. vvv whoops how did I miss that Vanadium fucked around with this message at 22:45 on Feb 16, 2010 |
# ? Feb 16, 2010 21:11 |
|
Anunnaki posted:Well, just having to distribute the DLLs with the .exe really isn't the problem so much as keeping track of which ones I need to distribute with it. When I tried sending my friend the .exe, I copied all the DLLs in the release folder, but he got an error about another missing DLL, which I had to find and send to him for it to work.
|
# ? Feb 16, 2010 21:13 |
|
Vanadium posted:As I posted in the Coding Horrors thread a while ago~ Scroll up a few posts, bub
|
# ? Feb 16, 2010 22:17 |
|
Mustach posted:Dependency Walker solves this problem. Wonderful, thanks.
|
# ? Feb 17, 2010 02:26 |
|
Anunnaki posted:Also, genuine question, what's wrong with GCC, compared to MSVC? The free version of Qt only comes with MinGW, so I'm stuck with that in any case. When it comes to statically compiling Qt, there are two problems: 1. You can't statically link mingwm10.dll, which is a dependency for Qt unless you remove some -mthreads options from the Qt build. The official position on this, last I checked, was that this doesn't appear to make things go horribly wrong so it might be okay. 2. It doesn't do dead-code removal. This will likely result in a compiled binary twice as large as compared to MSVC. Qt free version has supported MSVC since one of the 4.3 versions, which came out two years ago. You can download the visual studio Express Edition free from Microsoft.
|
# ? Feb 17, 2010 16:28 |
|
Zhentar posted:2. It doesn't do dead-code removal. This will likely result in a compiled binary twice as large as compared to MSVC. It certainly does do dead-code removal. I think you're referring to link-time optimisation (a distinct, related feature) which was only recently implemented and hasn't found its way into a stable release yet. Both have been implemented in CL for quite a while now.
|
# ? Feb 17, 2010 17:44 |
|
Whilst farting I posted:For some reason, if I don't have the while at the beginning, it only draws the very first pixel. However, I have gotten it working except for drawing straight up or down vertically. How would I accommodate for that? I have a feeling that's the errorCheck variable getting continually reset but I don't know why I'm having trouble with the while loop. You put the swaps in the loop. Bad graphics student, bad! Check for swaps and determine your xbegin/end/ybegin/end before you go through the loop. As a good practice in graphics, your drawing parameter (xbegin/end) shouldn't be used to iterate through the data. You need another variable, ie. x, tx, i, j, whatever to iterate through. The begin/end's should be treated as consts. In later graphics applications you're going to have to treat stuff like that as consts if you want to implement splines. Whenever you're iterating through an algorithm like that, you shouldn't alter the original drawing parameters. Otherwise it'll cause you a world of hurt if you do anything complex or attempt to vectorize stuff (like for the GPU). edit: yes I realize the wikipedia entry does swapping, but there's other ways to do it that are safer. Not to mention that as soon as you get into anything even remotely more complex, especially raytracing, you can cause a shitload of problems doing potentially unsafe swaps. Goreld fucked around with this message at 01:20 on Feb 19, 2010 |
# ? Feb 19, 2010 01:12 |
|
Quick C question. What does the following declare?code:
|
# ? Feb 19, 2010 22:07 |
|
DeciusMagnus posted:Quick C question. What does the following declare? Declarators are read inside-out, and you can parenthesize arbitrary declarators to specify grouping. So, e.g., int id; and int (id); are equivalent, and you can write things like: code:
rjmccall fucked around with this message at 22:28 on Feb 19, 2010 |
# ? Feb 19, 2010 22:21 |
|
|
# ? Jun 1, 2024 21:10 |
|
DeciusMagnus posted:Quick C question. What does the following declare? I think the parenthesis are there because [] binds more tightly than * does: code:
Edit: rjmccall explained it a bit better. See K&R Section 5.12 on Complicated Declarations. mr_jim fucked around with this message at 22:26 on Feb 19, 2010 |
# ? Feb 19, 2010 22:23 |