Release of RosAsm V.2.025a
in [ASM]
|
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: 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, Guga
From: Bertrand Augereau on 20 Sep 2005 12:11 Guga wrote: > 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, > > Guga > 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 news:433034a7$0$7868$8fcfb975(a)news.wanadoo.fr: > 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 :) I hope that you are payed on a base of "Number of Lines". :]]]]]]]]]]]]]]]] Betov. < http://rosasm.org >
From: randyhyde@earthlink.net on 20 Sep 2005 13:35
Betov wrote: > > > > 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" approach. > > > [...] > > > > 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, > Troll? If he's happy with his editor, why should he even have to read the documentation for your's? Cheers, Randy Hyde |