i've been slacking off and i have a little trouble restarting to program as well as solving some problems i had even before i slacked off
since i am learnign to program and more as i go i need some help
here is the source
attached below as .zip
problems:
1. the "star map" matrix first line gets generated on y coordinate pixel 0 for some reason (assemble to get the visual); on line 331 i fill the y values of the array of points
2. it seems main diagonal points are missing (x1y1 x2y2 etc)
3. i'm getting stuck on managing how to get this right. Normally i want the star map to be drawn on the center child window device context and i want it to resize properly along with the whole window. Preferably i want this to be done as neat as possible, i suspect with a mapping mode set to mm_isotropic.
4. advice?
[attachment deleted by admin]
1. The problem seems to come from when you draw the list of points - you're using both esi and edi to access the same array (at overlapping offsets).
The end result is that you get 0 for the y value of the last 9 points.
2. If the points are supposed to be random, then you may or may not get points on the diagonal - I wouldn't expect them to necessarily be there.
3. You have to regenerate the starmap whenever the window resizes, but use the same random seed (i.e. only set it once at startup). Although, depending on your formula, the starfield may not look the same after re-sizing. The other option is to generate the points for a 'huge' window, and then scale the co-ordinates when you redraw.
4. Start again - use this version only as reference; don't copy and paste from it!
First just do a single window with the starfield in, you can add the other windows later.
Also, try to do it without using the fpu (I recognise the example you've modfied to get to this, so I know why you have been using it.) You only need to use MUL and DIV (or possibly IMUL and IDIV): a*(3/4) is the same as (a*3)/4 -- you should use the second form to keep accuracy.
Get it right for 10 stars first, then change the numbers to make 100 :wink
On a preliminary look i think i got one of the problems:
The filling system for the matrix was: 1st_step{x0y0 x1y1 ... x9y9} 2nd_step{x0y1...x9y0} 3rd_step{x0y2...x9y1} ... and so on.
In my code 1st_step is missing so the main matrix diagonal doesn't get drawn. I have to go over the logic again to be sure of what i was doing, i only noted the big ideea down like formulas.
For the first line of the matrix i think its because the range of y is [0...5/7cyClient] not [1/7cyClient...6/7cyClient] as it should, but, the last line of the matrix gets drawn correctly(hmm). The first line gets drawn seemingly on 0 line of the child window because its coordinates are beyond that but cannot draw there instead since the hdc refers to a limited drawing area? I'll come back after i recheck all that again. * and / are comutative operations i don't see a reason to use one over the other. I'll pick the one that produces less clocks over least memory if posible as i try to minimize the code using non-fpu instructions. Using the FPU tought me to use it tough, and i think its faster than using only the CPU.
Think i should comment my code more? Since its my code i know mostly what it does but i suppose its hard to read its logic at a glance.
I use both esi and edi like this because i need two separate values cycling, and if i did it right and i remember also right, indexing through the array of points where x and y are double words is by indexing the bits between the values, 4 for the x value plus 4 for the y value i jump over is add esi, 8; same for edi. The rest of the logic i use is the one i stated earlier, dont' ask me why is it that twisted :), i ran into some problems when initializing the matrix the way i wanted and this is the first viable solution i found. The second one was doing {x0y0, x10,y10...} {x1y1, x11y11...}. This is because i "preplaced" the coordinates so they can't be laid but in these orders w/o anymore calculations.
raneti,
To address your original topic, the method that works for me most of the time is having two seperate approaches to writing code, the "bits" brain and the "app" brain. The "bits" brain is essentially that of making components, procedures, libraries etc ... where the "app" brain concentrates on writing applications, often out of some of the previously written bits.
This saves you from endlessly having to dream up new apps to keep yourself amused if that is the problem. Instead you make what you see as useful components which in turn make writing apps easier, faster and something like fun.
Quote from: raneti on October 30, 2006, 07:31:16 PM
For the first line of the matrix i think its because the range of y is [0...5/7cyClient] not [1/7cyClient...6/7cyClient] as it should, but, the last line of the matrix gets drawn correctly(hmm). The first line gets drawn seemingly on 0 line of the child window because its coordinates are beyond that but cannot draw there instead since the hdc refers to a limited drawing area? I'll come back after i recheck all that again.
No. If the co-ordinates are out of range, then you won't see the point drawn; they don't wrap. (I told you, some of the y co-ordinates are used as zero.) How about drawing each of the 'lines' in a different colour to help with debugging? :wink
Quote
* and / are comutative operations i don't see a reason to use one over the other. I'll pick the one that produces less clocks over least memory if posible as i try to minimize the code using non-fpu instructions. Using the FPU tought me to use it tough, and i think its faster than using only the CPU.
They are commutative 'mathematically.' However, integer operations don't keep arbitrary precission. As a result, (3*4)/5 does not give the same result as 3*(4/5). The answer should be 2.4, but it will be 2 or 0 depending which way you do it.
It is good to know how to use the fpu, for those times when integer arithmetic isn't appropriate, but it's definitely not faster in any way. (There are some tricks to do * and / faster than the mul and div instructions, but these are for limited cases, if you want to get into that.)
Quote
Think i should comment my code more? Since its my code i know mostly what it does but i suppose its hard to read its logic at a glance.
It always helps :wink (In particular for yourself when you come back to it a few months later and wonder what on earth is going on :lol)
If you want to write what you intend to do, in steps, in english (for one, what is the steps of the points -- {(0,1),...,(9,0)} could go anywhere in between) then we can take a proper look :U
I started getting a resistance to pure theoretical learning so this is my way of practical learning, learning as i do it and do it as i learn.
My plan on this is simple, getting this thing to be the framework in wich i work myself around a copy of Master of Orion 2(improving it i hope). I plan to include in this project of mine every aspect of programming i must learn and since in a game you can do it all it would work. The points are actually starting points where i would put icons(bitmaps) of stars and i'll make them interactive. I will do this all within windows api if possible(to aquire GDI and overall API competence) then perhaps make a little real-time battle engine in opengl or directx(to aquire further competence). Assembly is the real nuts and bolts language of choice for me. For example the OOP data hiding is really hiding data from me, i don't like loose ends in my code and methaphisical learning(as in knowing intuitively why a thing would behave the way it does, in the way OOP is handled and meant to work - it is RAD but for professionals i think). To get back to the point, this is the main event for now, getting the darn starmap to work(i think i'll call it galactic sector because there are no square galaxies :toothy). The formula i put in there looks like that because its meant to provide this rule for the star map: no star is meant to be too close to another star(and i wouldn't want Einstein twiching in his grave because i generate stars that would collide); so, i created a grid in wich squares stars are randomly generated, the squares beeing a certain distance from each other thus serving the purpose of separating each star in its own sector(in a 2Dish look at least) also beeing the horizontal and vertical range in wich the star is generated. From this formula came the way i had to draw them, because their position in the grid is predetermined, any other placement would have okward results. I'm having a hard time determining how i would make the whole thing dynamic so it would move and resize corectly with the window but still be interactive so i'm gonna make it a static window(1024x768 meant) and eliminate the top child windows and use a normal windows menu instead(i'll give it more tought after i fix the star generation glitches). In this game i mean to copy one researches technology so in the future i will have to do two things, copy the tech math or make one of my own, learn to work with files, implement the whole thing and link it to the rest of the game. My greatest unknown thing about all this implementing the whole TBS system and a save-game system so this whole thing can move past the 0 turn :)
In this journey i plan using all the tehniques and things i can gather like using all i learned in Iczelions tutorials and all i will learn reading about making a TBS game. It doesn't have to be extra flashy at first just a solid framework i can keep working on. I know making a game sounds like a job on wich C++ would be used and Python etc. but on the other hand i looked at some free souce projects(including FreeOrion wich i believe it would take a huge amount of time for me just to get aquinted to and also is moving too slowly and including work in too many programming environments) and i also find people who actually know stuff but even they can't read the code easely. Anyway this is meant to be a learnign trip at first.
A question: would the code work the same way if i take all the star map generation code and make it a function(w/o parameters at first, i mean will the code be using the stack more thus be slower or still work as the inline way it is now?) I want for example to generate different star densities like having a scarce, medium and dense predefined star sector with a certain number of stars or even allowing any number of stars(within possiblity limits). I mean of putting it in a .dll and making threads of everything of course for practice and good programming practice as well :)
The only way of making the bitmapped areas wich will represent stars be interactive is creating a new class of child areas who would receive the mouse input(i know no other way at the moment). Is there another way?
Where to learn tehniques of working with files and managing quite a large database of items? I think its easy to use the functions that work with files but the tehniques have to be learned(Perhaps use an existing interface? Learnign XML and the way to handle it in my programs?)
Quote from: raneti on November 02, 2006, 06:05:54 AM
A question: would the code work the same way if i take all the star map generation code and make it a function(w/o parameters at first, i mean will the code be using the stack more thus be slower or still work as the inline way it is now?) I want for example to generate different star densities like having a scarce, medium and dense predefined star sector with a certain number of stars or even allowing any number of stars(within possiblity limits). I mean of putting it in a .dll and making threads of everything of course for practice and good programming practice as well :)
Would it work the same? Well I'd hope so - assuming you write it correctly :P Would it be slower? That depends on how you use it. There is obviously a little overhead from having to push the parameters on the stack, then call, then get them at the other end, etc.. But in some cases, if you call a function regularly within a short space of time then it can turn out to be faster then a long set of inlines. Anyway, it's not going to slow it down by any noticeable amount. I would advise making it into a function for the flexibility, and readability. Dont spend too much time worrying about speed. Make it work first, then you can fix the bits that need speeding up (if there are any.)
Also, don't go out of your way trying to fit in every single 'technique' you can think of. Do what's necessary/appropriate for the task in hand - you'll pick up different things as you need them. (If you don't learn everything, that's because you don't need to :P)
Quote
The only way of making the bitmapped areas wich will represent stars be interactive is creating a new class of child areas who would receive the mouse input(i know no other way at the moment). Is there another way?
That is one way. Another is to check the point of each mouse-click against a list of squares representing the bitmapped areas - if it's in one of those squares then that bitmap was clicked. This would give you a lot more control (but require a little more work) and there are various ways to speed up this process so you don't need to check every single square each time (but first get it working. :bdg) And it avoids creating 200 child windows, which I wouldn't generally recommend.
Quote
Where to learn tehniques of working with files and managing quite a large database of items? I think its easy to use the functions that work with files but the tehniques have to be learned(Perhaps use an existing interface? Learnign XML and the way to handle it in my programs?)
Ask P1, he'll tell you (..to search! :lol)
You're going to have to do a little research on your own for this one - there are so many ways to handle these things, but they have been studied in detail by many people, so you shouldn't have any problem finding information.
Why don't i need to proto the winprok? Because of the OFFSET in this line :
mov wcex.lpfnWndProc, OFFSET WndProc?
raneti,
Something like that. It is because it is not being called using the invoke macro. The invoke macro is what requires proto-typing. There is a work-around for making it not necessary for invoke, either, but it is more trouble than it is worth.
Paul
Ok i detected the logical bug but my fix doesn't work:
My code drawing the stars makes use of y-values index 100th through 109th wich don't exist(they happend to be 0 so they show this way when drawn) and doesn't use these y-values:
0, 11, 22, 33, 44, 55, 66, 77, 88, 99 wich also explains why theres no main diagonal in my drawn matrix.
mov counter, -1
label11::
dec ecx
push ecx
mov ecx, 10
add edi, 8 ; x0y1, x1y2...x10y12, x11y13
add counter, 10
mov eax, counter
mov edx, 8
mul edx
mov temp6, eax
label10::
mov temp7, edi
.if edi > temp6
mov eax, edi
sub eax, 80
mov temp7, eax
.endif
mov eax, apt[esi].x
mov edx, apt[temp7].y
add eax, 5
add edx, 5
push ecx
invoke Ellipse, hdc, apt[esi].x, apt[temp7].y, eax, edx
pop ecx
add esi, 8
add edi, 8
loop label10
*this whole thing works in multiples of 8
I am using a counter wich increments once every inner loop completion(total 10 times), adjusted to a multiple of 8 to properly index the array. This logically separates the points by the way they are picked from the array into "ranges"(y-values index) 0-9, 10-19 etc. Because in each inner loop the y-values go into the next "range" i check for it helped by the counter wich determines in wich range i am currently and i adjust the y-value apropriately.
This, ugly as it is, doesn't even work alltough the logic seems sound(you have to click once on the center child window to get the ugly visual).
EDIT: fixed redundant .if logic i made with no positive result.
The above code still doesn't work alltough i went through a full debug. There are no logic bugs i could find either but still it doesn't work. I'm aware of .if beeing replaced with jbe alltough i used > and should have been replaced with jb(a happy accident for me).
Attach the whole project again and we'll take a look :wink
(It's unlikely the problem only comes from the short part you posted.)
It does come from that part somehow, reverting the code snip to its original makes it work like before.
Since my array contains the values and i'm just adjusting the indexing it should work, but it doesn't.
Nevertheless below is the new code:
[attachment deleted by admin]
Okay, the offending line is:
mov edx, apt[temp7].y
which doesn't assemble like you'd expect it to (which has a lot to do with masm almost ignoring square brackets) - what you actually get is mov edx,DWORD PTR [OFFSET apt + OFFSET temp7 + y] (I'm surprised it doesn't crash!)
You only get one level of indirection, so anything more (such as dereferencing a variable) requires an extra step to handle the extra indirection.
But, all you really need to do is use edi in the same way you've done with esi -- temp7 can easily be removed altogether..
.IF (edi > temp6)
sub edi,80
.ENDIF
mov eax, apt[esi].x
mov edx, apt[edi].y
....
On another note, you can make your program endlessly more readable (and somewhat faster/more efficient) by employing the following function in place of your fpu code -- which is almost all of the form A*(B/C)
muldiv proc valA:DWORD,valB:DWORD,valC:DWORD
;return = A * B / C
mov eax,valA
mov edx,valB
mov ecx,valC
mul edx
div ecx
ret
muldiv endp
Doing so will allow you to see what's actually going on, and then give you chance to re-arrange the code so it's clear that it works, and so you can see how to remove a lot of the messing about with temp variables (which only make it even less easier to understand.)
{There is actually already a MulDiv function in kernel32, but the extra overhead of calling it isn't worth it, plus it has to do other checking; and you can see what's going on with this one, allowing the possibility for certain optimsations (see below..)}
If you're feeling really adventurous, you can turn that function into a macro (an opportunity to learn how to use macros :wink) which handles the special cases:
- multiply by 0 ==> 0
- multiply by 1 ==> no need to multiply
- multiply by 2 ==> add eax,eax
- multiply by 4 ==> shl eax,2
- divide by 0 ==> error!
- divide by 1 ==> no need to divide
- ...etc...
which means all of this checking is done at assemble time (rather than run-time), the code is inlined, and you get more optimised code, in addition to more readable code.
thanks, you're a life saver :U Not sure what to do now i'll let you know if i made it through editing this post, i use that stuff in the invoke Ellipse as well.
Quotemov edx,DWORD PTR [OFFSET apt + OFFSET temp7 + y] (I'm surprised it doesn't crash!)
this is almost funny, tricky error. This is because masm treats [] only as index and not dereferencing(not the case for registers wich seem to be dereferenced w/o problems in such cases) ? Lemme understand this case tough, if it were apt[edi].y (where edi == 8 for example) it would've been assembled as apt[8+y]? I don't understand the +y part. In olly it appears as
00401611 |. 8B95 F02F4000 ||MOV EDX,DWORD PTR SS:[EBP+402FF0]If i remove temp7(from indexing i will anyway :) and use edi alone i will use y-values from indexing 0-9 because, it will sub 80 the first time around when it reaches apt[10].y wich instead turns into apt[0].y, after wich temp 6 get incremented and will always be ahead of edi. The result is i will use apt[0].y through apt[9].y twice then the code will resume doing it the old erroneous way.
I'll look into macros(hope they are covered in AoA). Do you know perhaps wich intel book handles memory arhitecture because i lost the chapters name. I need a good read on olly usage too i can't folow most of the interface.
EDIT: yep it works now, i got to figure how to make it work correctly(i ran out of registers and since i cannot dereference memory inside a index i see no solution yet).
Quote from: raneti on November 07, 2006, 04:08:01 PM
This is because masm treats [] only as index and not dereferencing(not the case for registers wich seem to be dereferenced w/o problems in such cases) ?
mov edx, apt[temp7].y gets assembled as
mov edx,DWORD PTR [OFFSET apt + OFFSET temp7 + y], which ends up becoming
mov edx,DWORD PTR [ebp+402FF0] because... (numbers made up to show the point)
- OFFSET apt = 402FE0h
- OFFSET temp7 = ebp+0Ch
- POINT.y = +4
==> (402FE0h + ebp+0Ch + 4) but the instruction set allows you to have a register and a displacement, so add all the numbers together and you get: (402FF0h + ebp).
QuoteLemme understand this case tough, if it were apt[edi].y (where edi == 8 for example) it would've been assembled as apt[8+y]?
Not quite. The assembler can't know the value edi will be, so it has to use edi, not 8.
If you use edi with the above example, then what you get is (402FE0h + edi + 4) ==> (402FE4h + edi).
So the register 'case' isn't different in any way, it's just masm's syntax (which you don't HAVE to use) that causes the confusion :wink
Quote
If i remove temp7(from indexing i will anyway :) and use edi alone i will use y-values from indexing 0-9 because, it will sub 80 the first time around when it reaches apt[10].y wich instead turns into apt[0].y, after wich temp 6 get incremented and will always be ahead of edi. The result is i will use apt[0].y through apt[9].y twice then the code will resume doing it the old erroneous way.
All I did was rewrite a small part so that temp7 wasn't needed - the logic of the code remains the same!! - and temp7 doesn't appear to be used anywhere else. So why would this suddenly stop it from 'working'? Are you sure it would've worked how you expected before?
Quote
Do you know perhaps wich intel book handles memory arhitecture because i lost the chapters name.
The System Programming manual will go through it in great detail, but why is this even relevant to what you're doing? You might want to look at the addressing mode stuff in the instruction manuals :wink
Quote
EDIT: yep it works now, i got to figure how to make it work correctly(i ran out of registers and since i cannot dereference memory inside a index i see no solution yet).
re-order and re-write the code so it's cleaner and easier to understand. Then you might be able to see why you're running out of registers and so re-organise a few parts so you have some to spare :P
QuoteAll I did was rewrite a small part so that temp7 wasn't needed - the logic of the code remains the same!! - and temp7 doesn't appear to be used anywhere else. So why would this suddenly stop it from 'working'? Are you sure it would've worked how you expected before?
I used apt[temp7].y in the Ellipse function as well. The code first moved edi value into temp7, afterwards it checked if edi is bigger than temp6 wih is a variable meant to control the indexing so in every outer loop (10 times inner looping) the indexing doesn't exceed its perimeter, wich is index 0-9 first time 10-19 second time etc. Every round of 0-9, 10-19 elements contains a group of x or y values by the case so in 10 rounds(or lines) of y values i got 100 y values. This is a 10x10 "board" in wich every cubbyhole acts as a containment and more and every value(star) in it has a different x, y value. If apt[temp7].y would've dereferenced the index correctly(the value inside temp7) the logic would've been perfect. If i take temp7 out i need a variable to do the work temp7 was doing. As i said before on this, its a logic bug if i just sub 80 out of edi everytime(happends once) it checks the control variable(temp6). Basically some y-values will remain unused and some will be reused(unintended thus a logical bug, hard to get a visual on if you don't acknowledge it first).
In short:
for(outer=0; outer < 10; outer++)
{
j++;
control += 10;
for(inner=0; inner < 10; inner++)
{
temp = j;
if( j >= control)
temp = j - 10;
right = apt[i].x + 5
down = apt[temp].y + 5
Ellipse(hdc, apt[i].x, apt[temp].y, right, down)
i++;
j++;
} j keeps incrementing onward and temp is used to point the right index;
temp = j - 10 is not the same with
j -= 10QuoteThe System Programming manual will go through it in great detail, but why is this even relevant to what you're doing? You might want to look at the addressing mode stuff in the instruction manuals
Alltough you explained to me i don't understand, i need to read about all this system to get the picture and understand. For now perhaps a way to use a variable(memory location) as index in an array to dereference would fix this problem however this hole in my knowledge will emerge again. I doubt i will understand tough, all i get now is that there are some memory segments in wich memory locations are numbered sequentially, wich, in fact beeing "virtual memory" its in fact a logical memory allocation not the actual phisical one, wich concerns me less in the present but more if i am to become a programmer; for example 402FE0h is the virtual memory location, ebp will contain the adress inside SS(stack segment) wich will contain the adress of temp 7(+0Ch i'm lost here i got too many ambiguous informations(notes not linked to a particular event in my mind so it could represent anything IMO) ). Anyway i would not find this on my own without theorethical knowledge. Perhaps playing Sherlock Holmes and rule out everything else i was perfectly sure on and remain with the "no matter how unlikely its the truth" bit wich i rather not practice but in extreme cases.
Quotere-order and re-write the code so it's cleaner and easier to understand. Then you might be able to see why you're running out of registers and so re-organise a few parts so you have some to spare
Probably i will use a memory counter instead of ecx and use ecx instead of temp7 if i won't find out how to use a variable as an index to an array.
My apologies, I overlooked what happened with temp7 ::)
Okay, so you can do it like this..
push ecx
mov ecx, edi
.if ecx > temp6
sub ecx, 80
.endif
mov temp7, ecx
mov eax, apt[esi].x
;ecx is already temp7, from above (one level of indirection)
mov edx, apt[ecx].y ;another level (two levels in two steps; you're only allowed one memory access per instruction)
add eax, 5
add edx, 5
invoke Ellipse, hdc, apt[esi].x, apt[ecx].y, eax, edx
add esi, 8
add edi, 8
pop ecx
loop label10
QuoteProbably i will use a memory counter instead of ecx and use ecx instead of temp7 if i won't find out how to use a variable as an index to an array.
I moved the push-pop ecx to the outer 'edges' since this is only where the loop-counter is needed - so then you have ecx to play with inside the loop :wink
You can't use a variable as an index into an array (in a single step) as you can only have one memory access per instruction (which is why you can't do "mov var1,var2"); you would need one memory access to get the variable to use as the index (temp7) and then another to get the array element itself (apt[...]). So, instead, you have to do it in two steps, with one memory access each. So, you get the index into a register in the first step, and then use the index from the register to get the array element in the next step.
For understanding the architecture, how the instructions work, etc, I think the intel manuals will give you the wrong type of detail.
You could try "Art of Assembler" http://webster.cs.ucr.edu/AoA/index.html or "PC Assembly" http://www.drpaulcarter.com/pcasm/ -- they are aimed at 'noobs' but it's not a bad idea to humble yourself and just work through it, you'll probably pick up some things you missed and fill those knowledge gaps.
No apologies needed, you must be a busy man. I started with P.Carter's but its aimed at nasm, beside that i don't remember seeing AoA or P.Carters saying anything about it, arrays i picked up from AoA but none of them used a memory location as an index, that was my ideea. I'm sorry i didn't kept a note when someone told me the manual and chapter i should read to cover memory management. I have to find him again and ask, all i have now is INTEL's "Architecture and Programming Manual"; pretty close. I'm starting to think INTEL's are the best on assembly manuals. I don't see the point of a programmer who can't debug his own code and i don't particularly like AoA because i don't like knowing to read Pascal and C++ when just one of them will do or learning HLA "perks" besides assembly.
QuoteFor understanding the architecture, how the instructions work, etc, I think the intel manuals will give you the wrong type of detail.
No offense but i don't see what wrong kind of detail would be for a programmer. I kept INTEL's reference book with me from the beginning learning how to use it. Since INTEL does the hardwired part its only natural that they should have the best manuals. I.E.
QuoteCHAPTER 5
FEATURE DETERMINATION
Identifying the type of processor present in a system may be necessary in order to determine
which features are available to an application. Chapter 23 contains a complete list of which
features are available for the different Intel architectures. The absence of an integrated
floating-point unit (FPU) or numeric processor extension (NPX) may also need to be
determined if software needs to emulate the floating-point instructions.
This chapter discusses processor identification, as well as on-chip FPU and NPX presence
detection and identification. Sample code is provided in Example 5-1.
I regard INTEL manuals as MSDN for Visual Studio users; they are a must have. Programming is not a hobby for me and since i'm doing an application with wich i can prove what i learned just keeping it to a handfull of instructions won't do.
Strange, the star map should scale itself with a constant seed since everything is done in ratios(i have doubts at rand mod n part but the whole 9%(10%-2%+1%) box in wich the star gets drawn shoudl scale anyway)
1. I achieve cxClient and cyClient in WM_SIZE.
2. I use the above values to set the height and width as well as coordinates for the child windows in ratios(wich it works dynamically as it should with MoveWindow).
3.I use the dynamicly obtained values i need(height and width of the 5th child window i'm drawing the stars on) passing them into g5width and g5height at the end of WM_SIZE message.
4.Still at the end of WM_SIZE i call up WM_USER.under construction i just notice i made sure the call to WM_USER runs once so the code wouldn't generate different star positions at each resize; at this point i think i need to generate the grid separately then run rand mod x(range) and rand mod y(range). Commenting out lines 272, 274, 275 shows the behaviour i predicted in epilogue. At this point i need a solution. I'm think using rand mod n and a single seed just won't work, i'm thinking using the "make a huge map then rescale" ideea you gave me but i never did such a thing looks terribly cumbersome(i haven't done any of this before too tough. One problem more too, i need the star coordintes at all times to use for the child windows that would do the hit testing for me. To do hit testing using calculations would be hellish.
I don't think i can pull using a constant seed dynamic star map because of the calculations involved. Be it b the grid box side wich is the range in wich i spawn the star. rand mod b would be r. b would be 9% of the wisth involved, or height. Lets say simply that this 9% happens to be 50 pixels at this time. rand mod 50 would yeld values equal to a if a<b and values equal to a-m where m is b*n, n beeing the necessary factor to making m close enough to a without going over. Every time the range changes the point changes coordinates for values a-m but not for values lower than b.
oook, scaling. Since i would draw a huge static map at first i would have static x, y coordinates. Taking a model square of side 100 with a point in its center. Scaling the point in the center to a box of side 50. 100 : 50 = 2 thus the point in center has now x= 50 : 2 = 25, y same. I think thats all the logic there is to it, besides from creating an array that needs initializing each time the size changes to hold teh new star coordinates. This will be fun when coming to bitmap scaling, i will just need the ratio and the right bitmap function. under construction
5.In WM_USER i fill an array of point structures with values using the globals containing the dynamic values of the child height and width. Stars are arranged in a grid also determined dynamicly(step: 10%-2%+1% adjusting the space within wich the star is made[rand % ...] and step: [...] + i * 10% wich makes 10 "elements" of each x and y, 10 lines, 10 columns, 100 boxes.
6. Each star having a predetermined(but dynamic[relative]) position gets drawn in ChildWndProc's WM_PAINT message.
The stars in a worst scenario would wobble inside the grid when resizing because of rand mod n calculations but the wobbles should distance themselves as the grid expands as i would enlarge the window or get closer as i minimize it. Nothing of this happens however the star map is static :dazzled:
[attachment deleted by admin]