Re: When to use Rosasm, when to use Masm?
From: Betov (betov_at_free.fr)
Date: 03/05/05
- Next message: Beth: "Re: 32-bit call w/ 16-bit return."
- Previous message: '\\\\o//'annabee: "Re: When to use Rosasm, when to use Masm?"
- In reply to: '\\\\o//'annabee: "Re: When to use Rosasm, when to use Masm?"
- Next in thread: '\\\\o//'annabee: "Re: When to use Rosasm, when to use Masm?"
- Reply: '\\\\o//'annabee: "Re: When to use Rosasm, when to use Masm?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 05 Mar 2005 14:31:27 GMT
"'\\\\o//'annabee" <'\\o//'annabee> écrivait
news:opsm51qyw63aagrl@news.braodpark.no:
> Honestly Betov, do you hate or like this way of writing code :
>
> This is the key "loop" of my translation of the directX9 tutorials to
> RosAsm. (The API tutorials in DirectX9 Documentation)
>
> Direct3D9.Render:
> ClearTarget D3DCOLOR_RED
> BeginScene
> SetStreamSource 0 DõVertexBuffer 0 sizeof_CUSTOMVERTEX
> SetFVF D3DFVF_CUSTOMVERTEX
> DrawTriangleList 0 1
> EndScene
> lea eax Dõesi + SkinWindow.FreeClientRect
> PresentToRect eax
> L9:
> ret
When i read others Sources, i look at two different things.
1) The formal way of writing. I mean does it look nice to my
eyes. Is it easy to the first sight to perceive the various
components of the source flow, and so on.
At this point of view, there are several things that i do
not like in your own writtings. (Sorry, but my considerations
tend to push me to be more and more "rigid' :)) at this point
of view...). To me:
- The Macros Members of a Statement should be separated by
a comma plus one space, so that the first sight could tell
what and where each Member is. (Each Macro Member is, at
least, one Instruction...).
- The Local Labels should _always_ be at first Row (and
the Local Labels Evocations -the jumps-) at the very end
of the Lines.
- There should never be any Space inside any Member. Whatever
length of the Member. For my own taste, it cannot be:
lea eax D§esi + SkinWindow.FreeClientRect
... Because, at first sight, i do not see how many Members,
and where they are. To me, it must absolutely be:
lea eax D§esi+SkinWindow.FreeClientRect
... because 'SkinWindow.FreeClientRect' is, in no way, a
Member of the Instruction. This is a Component of a Member,
that is made enough separated by the '+' Char, that my
aye sees immidiatly.
Of course these are very tiny formal details from an old
maniac, but my own evolution, in the way of writing, has
pushed me to be very 'rigid' on these details points, as
i have experienced too many times at what extend these
details may be killing, when not observed, and resulting
in "Typo-Type" stupid Bug, that i can take 20 minutes
to point out, after having read the faultive intruction
20 times, without having seen the trivial Typo.
One of the good criterias for the validity of a given writing
style is "How many milli-seconds do my eyes need to know what
is what?". If you have to look twice to see something,... this
can be improved... :)
2) >>>
> Personally I love the way I can choose the B or the U at will, and
> sort of reinventing my own language at any point in my applications.
> This is the real interessting thing about RosAsm macro language to me.
> Beside the incredibly intuitive datamangemnet.
I think you do well. There is, here, a very difficult problem
that cannot be exactly formulated:
On one hand, HLL-Constructs, HLL Macros and the like, _do_
improve a _LOT_ the readability.
On the other hand, if the "HLL-Building-Process" implies too
many levels of abstractions, these abstractions themselves
(the layers quantity) may become a difficulty for reading
(understanding) the Source Flow.
At least, it works like this for me: I see a Macro (same for
any call, by the way...). I right-Click on the Macro (-1, in
the abstractions layers). I see a Procedure using Macros, and
so on... at some number of abstractions layers, i am lost,
and understanding the whole thing becomes a pain in the ass.
So, the logical number of abstractions layers should, as far
as possible, be kept under a number that the human brain could
hold (keeping the overview). I do not know what is this critical
number. I suppose it depends on the IQ of the reader :)) , but
to me, it seems that over 3 abstractions layers it becomes
difficult to read. At 6, for sure, i am lost...
At that point of view, what you are doing seems to me perfect:
There are not many cases of 3 layers, and it was easy to follow
up, for what i have tracked down.
> Btw. It took me about 10 hours writing the two first Tutorial examples
> , starting blank and translating the header infos I need for each into
> RosAsm. The only problems was because I sometimes misunderstood the
> API. One of the things in the accompanying C source that made my
> particularly want to laugh was this enumeration constant :
> D3DSWAPEFFECT_FORCE_DWORD
>
> [...]
>
> the links :
>
> http://szmyggenpv.com/Tutorials/downloads/Direct3D9Tut1.Zip
>
> http://szmyggenpv.com/Tutorials/downloads/Direct3D9Tut2.Zip
Downloaded, but, i do not have DX9 on board... :(
I'll try to buy a review with such stuffs on a CD... ;)
Betov.
PS. For such Demo coming out with a number of associated Files,
it could be a good thing to zip them [In] Folder... ;)
- Next message: Beth: "Re: 32-bit call w/ 16-bit return."
- Previous message: '\\\\o//'annabee: "Re: When to use Rosasm, when to use Masm?"
- In reply to: '\\\\o//'annabee: "Re: When to use Rosasm, when to use Masm?"
- Next in thread: '\\\\o//'annabee: "Re: When to use Rosasm, when to use Masm?"
- Reply: '\\\\o//'annabee: "Re: When to use Rosasm, when to use Masm?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|