From: Bertrand Augereau on 20 Sep 2005 12:05
Thanks for the answers!
This is a...mmmh... original system :)
There has been a debate for a long time if the best representation for
source code is a bunch of ASCII files. I think it is, except if you can
provide all the tools that exist for processing text (regex,
preprocessor, and so on...)
(The file revision systems refer to CVS, SVN, VSS and such... )
From: Guga on 20 Sep 2005 12:06
Yes...i have forgoten to mention the incIncluder.
The incIncluder is simple to use. On the separated teams i posted
before. you can have
a) Team 1 --> Working on Main project...called game.exe
b) Team2 --> working on a part of the source code for the
particles...they can name their sources as particle.asm
c) Team3 --> working on a part of the source code for the Gui...they
can name their sources as Gui.asm
At the end of each team job (or if they only wants to test as the
actual stage of the develo´pments. The game source will conatins
something like this:
(Team 1 main work)
(Team 2 wants to insert his soruce here)
(TEam 3 wants to put his source here)
So, all it is needed is you put the incinclude preparse statement on
the main games source like:
When you assemble it, all different parts of the source will be merged
on the main app.
From: Bertrand Augereau on 20 Sep 2005 12:11
> Yes...i have forgoten to mention the incIncluder.
> The incIncluder is simple to use. On the separated teams i posted
> before. you can have
> a) Team 1 --> Working on Main project...called game.exe
> b) Team2 --> working on a part of the source code for the
> particles...they can name their sources as particle.asm
> c) Team3 --> working on a part of the source code for the Gui...they
> can name their sources as Gui.asm
> At the end of each team job (or if they only wants to test as the
> actual stage of the develo?pments. The game source will conatins
> something like this:
> TITLE MainCode
> (Team 1 main work)
> TITLE Particles
> (Team 2 wants to insert his soruce here)
> TITLE Gui
> (TEam 3 wants to put his source here)
> So, all it is needed is you put the incinclude preparse statement on
> the main games source like:
> PREPARSE incIncluder
> INCINCLUDE c:\Particles.asm
> INCINCLUDE c:\Gui.asm
> When you assemble it, all different parts of the source will be merged
> on the main app.
> Best Regards,
By the way, since you are taking a game as an example, I work on a game
(and artists tools that come with) that compiles roughly 1,400,000 lines
of HLL (maybe 2,000 of ASM :) ), 500,000 lines of script and thousands
of file, so physical organisation of files and dependency management
becomes quite important... You can't rebuild the world everytime :)
From: Betov on 20 Sep 2005 12:33
Bertrand Augereau <bertrand_myfamilynamegoeshere(a)yahoo.fr> ?crivait
> By the way, since you are taking a game as an example, I work on a game
> (and artists tools that come with) that compiles roughly 1,400,000
> of HLL (maybe 2,000 of ASM :) ), 500,000 lines of script and thousands
> of file, so physical organisation of files and dependency management
> becomes quite important... You can't rebuild the world everytime :)
I hope that you are payed on a base of "Number of Lines".
< http://rosasm.org >
From: firstname.lastname@example.org on 20 Sep 2005 13:35
> > Well, if I lose some of my source, then I certainly don't expect to be
> > able to assemble the code. I also wouldn't expect to be able to
> > assemble RosAsm code if half of the file turned up missing.
> This is simply impossible Troll:
Have you so quickly forgotten the fact that bugs can crash your
assembler, losing user data? Are you claiming that RosAsm has no bugs
that will ever result in lost user data? Are you claiming that RosAsm
users cannot make mistakes and accidentally delete code from their
source file, do an assembly (which, disasterously, overwrites the
"source file" deleting all the original code)?
Oh, I forgot, you're assuming that the user makes backups to prevent
data loss in these situations. It's always the *user's* fault, never
the assembler's design that results in lost data.
> The ony way we know of, for having "half of the file turned
> up missing", in a RosAsm Produced PE, is to take a big hammer
> and to knock hard and repetitively upon the Hard Disk.
Or accidental erasure, followed by a "compile" command (rather than a
"save file" command).
This is a big problem with the "source file is part of the EXE"
> > [...]
> > Well, that's a problem with the person not having given you the entire
> > source then. If I gave you half a RosAsm source, then you wouldn't
> > be able to assemble that either.
> This is simply impossible, Troll:
> You cannot remove half of a Source from a RosAsm
> produced PE.
Sure you can. You delete a bunch of statements to see what would happen
without them and then compile program program, forgetting the fact that
compile also means "save to disk." Arrrrgh!
> >> We all know that a library file is fixed.
> > Not if it's my library.
> This would be impossible with RosAsm, Troll:
> RosAsm does not do Libraries.
I do believe that's the point. And it's the #1 reason why almost no
serious assembly language programmers use RosAsm. Of course, if these
problem were corrected, there are many other problems RosAsm possesses,
but most people don't get past the "no libraries" part before moving on
to something else.
> > Automatic disassembly? That'll never work.
> The reverse is proven true by RosAsm Disassembler, Troll.
So now you're claiming that automatic disassembly works? As in
"perfectly"? We've been there before and even you admit that it doesn't
work perfectly. And the example Richard points out is a *good* example
of the problem with automatic disassembly. Let me give you another --
the disassembler disassembles four bytes $81256845 as a DWORD value,
but really it's a *pointer* to some object in the source code.
Reassembling the code at a different address in memory breaks the
pointer because the "DWORD 0x81256845" statement (or whatever) isn't
properly relocated. Sure, you can catch *some* of these, but the
halting problem guarantees that you cannot catch all of them because
differentiating code and data is an undecidable problem. The sooner
you realize this, and the sooner you add interactive capabilities to
you disassembler so the end user can help correct errors on the part of
your disassembler, the sooner you disassembler might actually be useful
for something real.
> > Like Randy said, ...
> Ah! That explains a lot, Troll... :))
Sure. Like why you're calling Richard all kinds of nasty names.
> > I shouldn't be tied down to the RosAsm editor though. I've never met
> > an IDE that I liked (unless you count the QuickBASIC editor), and I
> > doubt RosAsm's IDE would be any better.
> If you never took any look, what tree are you barking at,
If he's happy with his editor, why should he even have to read the
documentation for your's?