A.D.A. Amiga Demoscene Archive

I used to only code assembler, but after learning C and seeing that the compiler makes good enough code and I save time aswell as being able to test ideas and all. For 4k coding I might want to code pure asm though, but then again it is slightly more manageable with single source little intros :)

Out of interest, how many coders actually use c/c++ on Amiga and which productions have been coded in c mainly?

I know that Kiero used c for some 68k stuff like the intro Electricity and probably the productions released afterwards (like Metatag and Amsterdam Blessings). I remember Psycho/Loonies saying that the biggest part of The Castle was written in c. And obviously TBL uses it aswell.

Quite frankly, i don't see any reason why boring/time consuming tasks should not be written in c/c++ if it makes it easier and faster to do. It also means more time to actually work on the design/the look/the actual effects. But then again, i don't know shit about it :)

Anyone interested in doing some tutorials or maybe give an overview of what tasks can be done easier with c/c++?

Some task that can be quicker to code in c/c++:
- serialisation: your engine loads iff,tga,jpeg,lightwave,3ds, etc, converts it into it's own format, and save it in a stream. This way you can modify files and try without converting/etc, and you can use the generated stream once your done, with only few lines of code.
- loading lightwave/3ds files, if you dont want to convert them before, same goes for graphics file loading
- high level maths: imagine you want to transform a 3D point from world view to camera view, just to use it's z value as a parameter. In c++ this is only one line of code, even though it's not the fastest.
- effects parameters generation: pretty nice to tweak c/c++ code for splines etc, no need to worry about registers allocation and stuff
- profiler: count the amount of calls to a routine, so you can build statistics and know what to optimize in asm
- scripting engine

As i said, all of this can be done in asm, will take some more time to code, but will be indeed faster.

also, if someone big fans of asm only, him can be do this: write some algo on c, compile it without linking with providing asm source listing, and just 'clear' this code from 'compiler thinks'. best way of course it is just understanding what you want, and asap wrtie on c or on asm without 'fanatism' :)

@z5
as i know kiero write all ppc/warp3d stuff on C, and last tbl demo was write on VBCC (picture from oceanmachine.lha/bonus/).also i think (but who know) tbl just write all stuff for windows (and test algos, etc) and after it compile it over vbcc + optimization over amiga. But who know of course :)

- serialisation: your engine loads iff,tga,jpeg,lightwave,3ds, etc, converts it into it's own format, and save it in a stream. This way you can modify files and try without converting/etc, and you can use the generated stream once your done, with only few lines of code.

So this means that programs like piccon aren't necessary anymore? Sounds cool. From the very little experience i have, i found it annoying to reconvert the picture in Piccon with every little change i did in my picture.

A scripting engine sounds cool too :)

The fact that all this is slower in c than in asm, is this visible in the demo itself (slower framerate)? I noticed some slowness in for example the Electricity intro which was coded in c. Especially in the tunnel parts.

I spent years converting pics from IFF to raw chunky using piccon... and then I decided I'd implement the IFF format directly in the demo.. and it only took an evening to implement the loader.. I have wasted many hours on that damn conversion slave labour :) But shortly afterwards cheetah started to draw in Photoshop which wouldn't save amiga iff format (not correctly, and not at all in the new versions).. So the conversion boredom is back.. :/

@z5

for example i am very shiti coder, so, i choice C for some scene stuff becouse it easy to understand, easy to read, easy to test algos and easy to found bugs, all is easy. But also, with all of this, i do not know optimization methods, tons of effects realization, etc. And of course all of this in all case (i think) will be wrtie as 'slowly newbe shit'. not always maybe, but moral of this text is it:
if someone smart will write somethink on C, it will not be slower over asm (maybe some critical place, but on 060-66 it is will not be detected by eyes). And, if someone stoopid (like me) will write somethink on C or on Asm it will slower over smart asses :)

In other case i want said, not c/asm do slower stuff, but humans :)

Basically, C it is one big library which was write on asm. somethink do not need to someone (and they rewrite it by asm fucns) , somethink think that some C compiler generate bad code and start to choice over vbcc/sasc/gcc/msvc. somethink just write this big library (agayn and agayn - basically it is asm engines). Of course, it is not true on 100%, etc,etc but look like this i think. (it's all i mean for big project of course like demo, etc)

<parental advisory: controversial thoughs ahead>

My take on the asm vs C debacle: coding in asm, you have to care about the details a lot to get something onto the screen. coding in C, you can afford to care a lot less. So, in effect, if you really care about an effect you can code it in C and then optimize or re-engineer some parts in asm and get very good results, but if you don't really care you'll get the whole effect in C ("I don't have time to optimize" syndrome) and as we all know here an 68k@50 is not an x86-64@2500, so the whole thing gets to suffer in regards to speed.

</parental advisory: controversial thoughs ahead>

Yes I think that's true. You can gain a lot of speed with doing stuff in asm on Amiga. Or if someone would make a demo completely in C, I think you should not do a 1x1 chunky-demo in 320x256 like so many C-demos on Amiga out there :)

For your information, I turned to half c/half asm around 1999. "NewWorldChild" (1999) was my last pure asm stuff. On my WarpOS period (deathtrial), the engine was in C and the whole 3D engine in ASM.

BTW: dealing with PPC, the asm question is different: there are 2 ASM ABI format, one used by warpos, the other used by MOS/OS4. registers have different roles, and function passing differ: it's impossible to re-use. (there is also a light difference between a MOS ASM and OS4 ASM :-). ( Note: warpos is now the only exec format able to run on all amiga PPC os, and its file length is also shorter.)

the public karate engine then, is 68020 but also made in C and asm, but its code is *quite* ugly from my point of view now, even if it implement some sort of object coding. I'm actually refounding a complete C++ architecture, with "100% reentrant code, 100% hardware independant", dealing with the "design pattern" state of the art: as a matter of fact, there is actually no reason why it should't work on the same hardware configuration as karate.

I totally agree with Winden.

Although I wrote everything in Assembler back then (and most things ran fine on 68030), I would probably mix languages (C/C++ and ASM) for "todays"* 68060 world.

Have a look at this highly recommendable book by Michael Abrash (a code guru(!) who helped optimizing Quake):
Graphics Programming Black Book

especially the first chapter which kind of wraps up this almost religious issue is highly interesting:
The Best Optimizer is between Your Ears (PDF)

I can only recommend that you download the whole book if you haven't already done so. It went out of print some years ago and is no longer available elsewhere. Luckily I own one of the last copies.

The basic point is that most time of a runtime is spent in only a small part of the code. If that part is badly implemented, it doesn't matter if you have done that in assembler or in C or in any other language.

Taking it the other way around it doesn't matter if some code which is only called once or seldomly (like loader, setup, whatever) is written in C and might thus be marginally slower then handcrafted assembler code. Please note the crafting-bit. Assembler is a craft and has to be learned properly. Beginners assembler code is almost certainly going to be outperformed by common C-compilers. Unsurprisingly this brings us back to what Krabob said earlier. He compared his coding skills against the gcc and lost many times. And this should not teach us that Krabobs code is poor (which it surely isn't). It should teach us that C-compilers are quite good (surprise, surprise).

Just my 2 cents.

I love you all and agree with all that has been said so far :)

---
* Of course there is no "today" in Amiga programming and it is all about the fun anyway.

looks like kufa do not made article for jp#15 about mixing ?:)

Looks like i was busy with my new job :)
Article is actually at a 90% finished state, i just have to re-read everything and re-test all codes.
I m also adding a "how to compiler under visual studio" tutorial with some sourcecode as well. I'll finish it when my gf will be in holidays, so in two weeks time :P

kufa, so , article is not so 'amiga related' ? becouse strage that you write about 'compiler under visual studio'. Why i ask about it, becouse i write for my mag (which will be cooperate with 'kubika' web magazine) article about mixing too. How big your article right now , and about what amiga compilers you talk about in this article ?

maybe kufa talks about cross compilation.

BTW, do you know this excellent thing:

http://amidevcpp.amiga-world.de/

krabob, i download it some time ago but do not tryed still. How it ? Tons of bugs of course ?:)

same as you, DL but no test yet :-)

Yeah i was talking about cross-compilation. This "how to compile under visual studio" article is inspired by the tbl toolchain, explain how to replace visual studio's cl and link to be able to compile your code using cross compilers without using any makefile. (kind of)
Is it also what you are working on?

Btw i didnt like amidevcpp :)

I don't see why everyone is so wanting to integrate cross-compilers into VS. Is it to make compiling "easier" or what (???) All you need to cross-compile is this GCC toolchain here: http://zerohero.se/ , some basic Makefile skills and type "make" into Cygwin Bash-shell ;) It couldn't be easier. There are lots of nice free source-file editors out there too!

If we're not careful people will lose the GNU toolchain skills then we'll have to rely on M$ for every compilation on ALL platforms - nightmare scenario :-)

@kufa
I am only write about mixing with compilers which works on amiga only. Basically about vbcc/gcc(stormc), and somethink about sasc. I write about object linking, about inserting asm directly into C code (like __asm() ) and about assembler inline fucntions (like __reg() ). All of this with ppc/68k examples for easy understanding.. somethink like you do ?

Your part about VS cross-compiling, it also in base of 'mixing with asm' topic or as one more different/easy think with C compiling on amiga ?


@klipper
maybe kufa mean replace vs cl and link on gcc-cross ones, and use vs only as ide ?

> I don't see why everyone is so wanting to integrate cross-compilers into VS.

Does the tbl chain use VC6 or dotnet 2002-2003 or dotnet 2005 ? They are all quite different. devcpp is some kind of clone of VC6, but at last it uses GCC and free stuffs, I like this aspect because I can also target the linux world with it. and BTW I actually tried amidevcpp a bit:
It seems you just have to change a combo with possible target (mos,os4,classic,aros) and you can generate an exe for each very quickly. the "monster pack" install the whole devcpp package AND each system devkit !!! I have to take a closer look, but no sign of bug ATM.

But I've heard you can use GCC with VS dotnet. dotnet has some nice features like "replacing a name in all the sources in one clic", things like that. But to my mind, the only real thing that matter for developping is how a debugger can be integrated.
I mean, you execute your 68060 stuff with "F5" . Does it throw an emulator ? And if it does, can you put a breakpoint in the source ? How could it work ?
No, I think the TBL guy compile and develop for intel, run and debug on intel, and THEN port it back.

klipper: because VS is a very good IDE that a lot of people are used to?
and who the hell are "we" (you) to decide if people should lose their "GNU toolchain skills"?

@krabob

btw, what about amidevcpp, this is in theory will be ok 'just choice target'. In reality (i was try some) for aos4 need to do tons of modification, and without aos4 into hands, pretty hard to make good os4 binary, from big 68k project.
But anyway, idea is good. Just need to do some more 'devpacks' for it :)

@klipper: visual studio is by far the best IDE out there, and for instance having intellicense save alot of time (and if you use visual assist it s even better). VC 2005 is free btw :)

@kasie: i was working on 3 different things: what you are doing, then how to use compilers under windows/cygwin that produce amiga outputs, and finally how to use them properly in visual studio without having to use a makefile.
And yeah the vc thing is only an example on how to replace cl and link to not having to use makefile projects.

@papy krabob: for the solution i explained you can use any version of vs.net. Regarding the output executable: if you do proper cross-compiling, you can output a windows executable that will be run from visual studio, and that will start a winuae and start your compiled amiga executable. Or you can do cross-platform programming and have a clean windows executable, and rebuild for amiga the resources intensive functions.

Btw we should exchange some mails for the article thingie!

/kufa

@kufa
Where do you plane to release all of your stuff ? in jp#16 ? i ask about it, becouse we will cooperate with 'kubika' web magazine, and our warp3d amiga executable diskmag, and, maybe you will be in interest to do somethink from this 3 thinks for us :)

We have chosen to integrate into MSVC for the following reasons:

* Familiarity with the IDE: Most of us use MSVC every day at work, and therefore we are most comfortable with MSVC as editor and IDE. This is the #1 reason why we chose MSVC.

* One tool for editing code and projects and controlling builds: By having the projects built as native MSVC projects, then MSVC will handle dependency tracking on C sources (no need for "make depend" or the likes). Adding/removing files is done in the workspace view, rather than editing a separate text file. We like that.

* Known way to integrate a cross-compiler: The PS2 development toolchain integrates its cross-compiler by replacing cl.exe / link.exe. It's not a very clean solution but it works satisfactorily and takes just a small implementation effort.

There are some drawbacks:

* MSVC doesn't do dependencies in assembly code: Dependencies are probably not checked properly when editing assembly code, so sometimes a clean build is required after changing include-files or getting latest from the source code repository.

* No debugger for Amiga projects: Integrating a remote 68k debugger into MSVC seems to require an inordinate amount of plugin coding (it seems to entail nearly as much work as implementing an entire new language) so for now we have two choices -- if all the project's code is available in C, debug the x86 build natively, otherwise run an assembly-level debugger in WinUAE/target hardware.

I just spent some hours with VBCC and WinUAE, trying to set up a tool chain that allows me to cross-compile C-Code from the PC and then link with ASM-Code on the Amiga side from within WinUAE.

VBCC comes with the mixasm example that compiles, assembles and links on the PC. I am interested in only doing the compiling on the PC and then assembler other objects and link on the Amiga. PHXLNK seemed to be an obvious choice and worked well for the VBCC minimal example. But unfortunately, I couldn't produce a working executable for the mixasm example using PHXASS. I ran into a problem with undefined symbols, seemingly for some construction and destruction routines (___DTOR_LIST__ and ___CTOR_LIST__). Some Internet source recommended just defining those and so I did. Although this satisfied the linked, the resulting executable did not work and crashed the Amiga.

Here is my command line (in VBCC:examples/mixasm with vlib pointing to the VBCC libs):

Obviously I am doing something wrong. Any ideas?

I solved my problem with undefined constructors/destructors in the vbcc mixasm example, as described above. For those who are interested:

The linker needs to know about vbcc-style constructor types (option -Cvbcc, see vlink manual section 2.3). Of course, the correct vlink options were visible in the examples/mixasm makefile from the outset. But I simply was not clear about every option in the makefile and somehow assumed that I could replace parts of the toolchain with other tools from the past (9 years of absence didn't contribute to a better understanding in this case). With a bit more research I found out that this was not the case, but luckily also not needed. Phxlnk reached the end of its lifeline and is now officially deprecated. Its author continues on the vlink project, which is part of the vbcc distribution. Voila, there was a new linker that could be used.

Using an up-to-date version of vlink compiled for Amiga, I was able to produce the desired effect of linking on the Amiga side.

But somehow, as I went along and found out about how I could do it, I was no longer sure if I really needed to link on the Amiga. It appeared to me that vasm (also part of the vbcc distribution) would be well suited to assembe some assembly routines, if needed. This might require some modifications to existing sources, but would ultimately come with the benefit of running the complete build process on the PC.

Those of you that cross-compile FOR Amiga and also have some assembly routines here and there: is this how you do it?

We do it all under Windows, using cross-built versions of vbcc + vasm + vlink. vasm is not as good as phxass but good enough for our purposes.
I'm not sure how up-to-date hitchhikr's package is but if he has the latest vasm in there then you can use things like REPT statements and whatnot.