Thread: height field to sphere?

Originally Posted by Redrobes

If you just want to keep it on top of the main window then you can use the SetWindowPos() func and put in the flags to set up the Z order so that its higher than the main window without being topmost. You can use topmost but they bug the hell out of me when using a dialog app. But sometimes they can be useful.

choice tip.. i haven't seen that mentioned before and something you'd only intuit after having been round the course a few times.

i used vc++e for a while, so i'm familiar with resource files. imo it's the principle of a 5 meg compiler install being as effective as the microsoft install's analogue to the urban sprawl of phoenix or greater los angeles. identical audio routines often perform faster in fclt than vce (really!), which otherwise has nothing to offer me except 'kid gloves'.

having accumulated most of the commands to create and use standard controls in the .cpp file, i'm ~over the hump and things are generally easier now.

The best way to keep dialogs on top of the main window is to make the main window the parent window of the dialog. That way there won't be any confusion about Z ordering (child windows are on top of the parent and, if modeless, can swap Z order back and forth as the user clicks on them).

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx is an excellent discussion on dialog boxes in Windows, including building dialog templates directly in memory without having to use a resource compiler (.rc) file.

Originally Posted by waldronate

The best way to keep dialogs on top of the main window is to make the main window the parent window of the dialog.

done. past the trauma of first app with dialogs (and learned what topmost means explicitly!)

added the updated app in itw thread, and now it's time for me to dig into procedural territory (ha).


..question (...)

obviously using a hacked bitblt code to display, (which i presume means to everyone that i'm using a pointer to write to the image array) and i've noticed that my RGB has to be written BGR... i was quite puzzled when my water was orange..

is this correct, or am i, as i suspect, writing one byte off? i'm sure i'll be able to adjust this when i've added the routine to export the fullsize bitmap and examine the top left and bottom right pixels...




as said, copied from someone who has a deeper understanding of what they were doing..

void deinit_framebuf(void) {
SelectObject(pDC,old);
DeleteDC(pDC);
DeleteObject(framebmp);
}

void init_framebuf(void) {
HDC hdc;
BITMAPINFO bitmapinfo;
hdc = CreateCompatibleDC(NULL);
bitmapinfo.bmiHeader.biSize=sizeof(BITMAPINFOHEADE R);
bitmapinfo.bmiHeader.biWidth=1024;
bitmapinfo.bmiHeader.biHeight=-512;
bitmapinfo.bmiHeader.biPlanes=1;
bitmapinfo.bmiHeader.biBitCount=32;
bitmapinfo.bmiHeader.biCompression=BI_RGB;
bitmapinfo.bmiHeader.biSizeImage=0;
bitmapinfo.bmiHeader.biClrUsed=256;
bitmapinfo.bmiHeader.biClrImportant=256;
framebmp = CreateDIBSection(hdc, &bitmapinfo, DIB_RGB_COLORS, (void**)&framebuf, 0, 0);
pDC = CreateCompatibleDC(NULL);
old = (HBITMAP)SelectObject(pDC, framebmp);
DeleteDC(hdc);
}



for (y = 0; y < 512; y++) {
z = y << 10;
for (x = 0; x < 1024; x++) {
*(framebuf + z + x) = RGB(blah);
} }

Windows does indeed do BGR as the default byte ordering. If you're using the RGB(), GetRValue(), GetGValue(), and GetBValue() macros then it's a non-issue from a programming standpoint. If you care about alpha, there are analogous macros for working with RGBA and alpha values (I think they were defined in the DirectX SDK). Alpha is usually defined as BGRA pixels, but some accelerators might use ABRG or other format; sticking with the DIB sections will ensure BGRA, though.

Depending on the processor, it may or may not be faster to make an array of pointers to the first pixel of each line and then address the line as framebuf[y][x]. For block clears, consider doing a 32-bit memset operation instead of pixel-by-pixel activities. If you know your instruction set, you can get even more performance by using MMX, SSE, or AVX instructions. If you're looking at that level of optimization, though, you probably ought to switch algorithms...

it's nice to know it's not me.. i'm used to muddling through such things (eg. the standard biquad reference for audio, the rbj cookbook inverts signs on a set of coefficients) as there are a lower percentage of people in audio willing to assist others. it's refreshing to have someone say, "this is the right format.."

..it could be a few more years before i become concerned with the other things you mentioned i think i have PTSD from the windows sdk and i own the hardcover..

Yeah that looks about right. Dont forget about that SetDIBits call I said about in another post or thread some time back. It can update the whole kaboodle in one call and its optimized by windows to do that job.

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

but if its working ok with what you have then its not too bad.

i'm currently using BitBlt. it seems quite fast to me.. iirc my preview mode is still in the order of 6 million 2nd order interpolations and i'm getting ~2-4 frames per second on my lappy.. the app is in this thread - http://www.cartographersguild.com/sh...pping-software

thanks for the reminder... i admit to being a ~BASIC linear, inline coder.. very little use for structs and classes in 1 dimension so i haven't had much practical experience with many OO procedures

procedural terrain, climate, rivers et c. are next (so still playing catch up) then national regions, cities and roads.. (do not anticipate quality) which should stretch my legs some.

Procedural Terrain is easy. Good-looking procedural terrain is fairly easy. Physically plausible procedural terrain is hard.

Climate is easy, basically being a lookup into a table by seasonal rainfall and temperature. Moisture transport is hard. Heat transport is harder. Moisture transfer and heat transfer are interdependent, which makes them harder.

Rivers are straightforward: liquid water flows downhill. Getting the water uphill is hard (it's dependent on both moisture transport and heat transport).

TY i expect that if i complete the course i'll report the same. in physical modeling i am not a stickler for perfection.. too tedious. one of the most enjoyable self-relevant functions is the amount of correlation between reality and what can be produced by simple (sometimes 'ideal') methods. i expect you also got most of the enjoyment out of wilbur implementing each new function and gauging the results.

i like to be useful, but i'm not particularly ambitious about being "what people use". if public utility wasn't a part of it i'd spend all day outside.

having spent a decade emulating specific, mercurial items, emulation at a more encompassing scale should broaden my procedural thinking.. but given meagre accreditation (while i certainly have received enough praise for synthesizers, i am quite aware of where i am not qualified to claim accuracy as i do not have eg. academic funding requiring authoritative correctness.. which is most fortunate because this ultimately limits me to my own discretion) i know there is as much folly at either/any scale and am consigned to enjoy the process rather than sweat it (lol and the occasional, inevitable extricative whinging directed at the precedent..)

:p