A.D.A. Amiga Demoscene Archive

As I am inbetween productions, I was considering testing out C development for the a1260. It's a thought I've had for quite some time, and now I seem to have both time and motivation. I've had a glance at Noname's brief but good article on Prototype 1 (http://www.dig-id.de/?p=117) and two things (at least!) where quite interesting to me. The toolchain seemed somewhat complex, and it would be interesting to hear different perspectives from people who actually do Amiga demos written in C. That is, for example, which setup people tend to use in terms of chosen compiler etc. I would do my stuff on a Windows based laptop with Cloanto Amiga Forever (so essentially, WinUAE). It's also the setup I have when working in AsmOne.

The other thing that really hit me in Noname's article was that it wasn't worth crafting an assembly texture mapper as he didn't gain any speed. As he knows his code, that therefore tells me that C is actually very efficient for demo development.

I understand that many have asked about C on A1260, but I hope that people are stilling willing to share some thoughts. Of course I wouldn't go about converting Kalms' c2p into C, and just call it instead, so let's start with suggestions for a good development environment.

I use vbcc/vasm and make on macos. Sublime for editing. Compiles a whole demo in 1-2 seconds. Uae, editor and terminal spread across 3 fullscreens which I swipe between. Best setup I've ever had.

Like Loaderror, our toolchain consists of VBCC, VASM, linking everything with VLINK and GNU Make for the Makefile. (For Mac I have created Homebrew formulas)
We also have created a startup that i somewhat semi-system-friendliy, so we can debug with printf & assert.

My biggest obstacle was to get the Makefile to work, so I will include it here to point you in the right direction:
https://gist.github.com/tditlu/ccf93d0c0c700b8575218ad3a9931577

That sounds like a good setup indeed. Working in modern editors in a modern os. My setup would then be win10 and Visual Studio Code. How do you go about Amiga libs for vbcc? I've seen that there's an Amiga build of vbcc, but I would be surprise if those Amiga libs are in the general release of vbcc.

What's your experience in terms of performance? Obviously YOU would have a larger asm effects codebase, where it makes good sense to make calls to those "old" asm routines from the C framework. But for new effects, does it really make sense to write those in asm or is C really "good enough"? I'm looking somewhat into pros and cons, as I also have a few asm based sources, and would like to figure out if "going C" is a good investment. I would be able to produce stuff quicker and more easily, and those are big plusses...maybe even the biggest ones. But then there's the Investment of building a new system, but I suspect that it actually isn't such a huge task afterall. What was your incentive to go C?

Ah, thanks Todi. You posted while I was writing the other stuff :-)

Updated the Gist link, just so you know...

About building a new system, it's not necessary, just use C for your new routines and asm for your old.

Really interesting! I right now sit with the feeling that C for demomaking is much more widespread than I had thought.

Ohh, I forgot, also have cross-compiled mingw32 binaries for windows, located here (updated them to latest version):

https://github.com/tditlu/scoop-amiga
http://todi.se/scoop/vasm/1.7h/vasm-1.7h.zip
http://todi.se/scoop/vbcc/0.9e/vbcc-0.9e.zip
http://todi.se/scoop/vlink/0.15d/vlink-0.15d.zip

Luxury! Now I know what my evening should be spend on.

I'm doing the same as loaderror pretty much. VBCC, VASM, make, Sublime Text, FS-UAE etc on a Mac. All my image converters and other tools are in Java but I should really move to something else for those. Perhaps Python.

I got the initial package with the compilers, targets and a working makefile too I think from hitchhikr here many years ago. For the latest VBCC/VASM (for Mac at least) you need to compile from source.

I find that when writing C the speed is decent for a lot of 060 stuff although I'd still code long loops and drawing routines in asm.
On a500 it's probably best to code all loops in assembly. But on both it's great that you can first prototype routines in C.

I'm glad to finally see this discussion. As I said in my initial blog-post, a lot of people already code demos in C for 060 Amigas.

Our setup is very similar - currently vbcc/vasm/vlink/gnu make to generate the Amiga Binary. My old assembly-based demosystem has just been turned into a linkable object. Moreover, we now also got an API-level compatible, Qt-based alternative implementation by Hellfire that allows us to code and run completely on Windows and without using WinUAE. This is really good for debugging and quick turn-around times.
Whenever we need new functionality, we just add it in both implementations.

We also have a profiler that allows us to visualise the time taken for different parts of the code as one stacked vertical bar per frame over the entire run-time of the effect. This is indispensable for identifying bottlenecks which then get special treatment. We also still write inline-assembly where it makes sense, i.e. only after profiling.

That's definitely not always the case. VBCC translates your code pretty much 1:1 into assembly and has to follow certain rules and limitations. So you should always double-check if your C code actually translates well into 68k-asm or not (vbcc can write the generate asm-code to disk). For example it has some trouble handling chars (8bit pixels) in 32bit registers.
It's often possible to create much better asm-output by simply expressing your C code differently. Always check the asm-output for your innerloops, most of the time you can improve it by 10% and often more.
You also can't express certain things in C, e.g. addx.

That being said, the C output is absolutely sufficent for 90% of your demo code.
Even if you can come up with better code for one of your functions, it probably takes you an hour (or even a day) while the compiler does it in a fraction of a second...