Hi Homer,
I respect your preferences and I think it?s good to have more than one model to enrich each other. Nevertheless, I have to correct you in a point where you are not right. The execution speed of any ObjAsm32 application is as fast as any other conventionally written assembler application. Last versions also reinforce the compilation speed with precompiled objects making this framework, all in one, the fastest we have yet!
I?m completely convinced that we have broken the old paradigm of programming comfort vs. execution speed. The complexity of the final macro implementation responds to our efforts to optimize the code for x86 processors balancing the u and v Pentium pipelines with minimal code size.
On the other side, it must be clearly seen, regardless of the model you choose, it is only a tool to write your application and it lies in your hands to make the best out of it.
I know you are a free thinker, but I?m surprised you haven?t tried the ObjAsm32 before. Perhaps the release of the new 1.3c version gives you a chance to try it and experience the power of the package and then, hopefully to change your opinion.



Posted on 2005-05-07 13:05:05 by Biterider
Heya Biterider :)

I see you've implemented the "static objects" stuff I recently discussed with Ultrano :)
We called them "non-virtual classes".

I have not applied your oop model because I don't understand it.
If you are willing to help me with a couple of simple classes, I'm willing to try it.
OK I've just installed 1.3C and am looking at the documentation.
Since I don't do anything by halves, I'd like to write an iocp server class and the handful of base classes it requires (I don't see any support in your object base for socket stuff, is it there?).
Expected Requirements : a Socket object class, an Overlapped IO event object class, a Client object class, an IOCP class, an IOCP WorkerThread class, a Thread object class, a Protocol class which implements IOCP class, and an application window class to house it all.
This might sound ambitious,? but if this stuff is decent, then these classes are useful additions to your object base anyway.
If you agree to help me translate the above module(s) from a given C++ source, I will volunteer to join your team in regards to 3D, and particularly, OpenGL support.

Addendum : Have translated CSocket, CEvent, CManualResetEvent, CIOBuffer, CIOCompletionPort, CSocketServer, CSocketServerWorkerThread etc to ATC while I waited for a response :|

Posted on 2005-05-08 03:18:48 by Homer
wildgnu - I did not elaborate on the shortcomings of ATC, which is unjust.
It is single-inheritance, like C++ is.
Each class can inherit from one, and only one, previously-defined class.
I am unaware of a depth limit, but if there is one, it would be masm's 30-something nesting depth limit.
Base classes don't inherit from IUnknown, they don't inherit from anything.
If you want to use ATC with COM, you need to look at my example D3D9 stuff.
You will see that I either define IUnknown class and inherit from it, or I redefine it at the start of each class, depending on which example you are looking at (I left my early examples in their original state so that other authors could follow my trail).
As Ultrano stated, ATC was written as a C++ wrapper.
He wanted to call C++ stuff from asm.
Then he saw he could do the reverse.
Then I pointed out that it could be adapted for COM support.
Then my code started looking very different..

That sounds great. I don't like multiple inheritance anyway so that is no problem. I'm going to get started on it right away. Meanwhile I have decided to write a small functional game engine in x86 assembly language. I haven't decided whether I want to bother with D3D, use OpenGL or possiblity during the initial phase just use GDI calls. Still doing research in that department.

Thanks EvilHomer and Ultrano for the links. I'll get back to you if I have any questions or have a neat program to show off. Thanks agian for all the help.
Posted on 2005-05-08 10:06:24 by wildgnu
I'm actually taking a sabbatical to learn the ins and outs of the ObjAsm32 model at the moment.
It's about time I did :)
From what I've seen so far, its capabilities and internals are almost identical.
Only the macro syntax changes pretty much.
One stark difference is that ObjAsm32 requires an object definition to have an "ObjectID", kind of a class id, which you must define and ensure is unique (no checking).
ATC handles that by generating the IDs for any classes you used, at build time.
They'll always be unique, and we can still take advantage of them at runtime (for example, to determine what kind of object lays behind a given pointer..)
Posted on 2005-05-12 22:15:17 by Homer