need help restarting and now continuing :)

[Tedd]

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).

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]?

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

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?

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

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

[raneti]

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?

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:

Code Select Expand

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;

Code Select Expand

temp = j - 10 is not the same with

Code Select Expand

j -= 10

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

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.

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

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.

[Tedd]

My apologies, I overlooked what happened with temp7 ::)
Okay, so you can do it like this..

Code Select Expand


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


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.

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.

[raneti]

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.

For 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.

CHAPTER 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.

[raneti]

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]