Amiga democoding?
category: general [glöplog]
The other thing to remember is that 68k asm really rules, so its almost a shame to use C. Its not like on Intel, where you really DO have to be insane to voluntarily code Asm ;-)
68k asm suck compared to ARM asm, but i still perfer doing ARM-stuff in c/c++. It might not be a pain to write, but maintaining asm is just pure pain. No matter cpu-architecture.
must agree to xeron.
MC680x0 register structure (especially the possibilities to
address 'em) are far easier compared to x86 architecture.
Additional the declaration of binary,hex or decimal values
is more comfortable, because I'd rather write $ff than 0xff.
Although I'm not in C/C++ programming (at least far to less for doing effects etc.) I do hack my machine in ASM, plus I'm still a dumbrain concerning chunkybuffer stuff the classic chipset is done until now.
MC680x0 register structure (especially the possibilities to
address 'em) are far easier compared to x86 architecture.
Additional the declaration of binary,hex or decimal values
is more comfortable, because I'd rather write $ff than 0xff.
Although I'm not in C/C++ programming (at least far to less for doing effects etc.) I do hack my machine in ASM, plus I'm still a dumbrain concerning chunkybuffer stuff the classic chipset is done until now.
Its not like on Intel, where you really DO have to be insane to voluntarily code Asm ;-)
It's kinda interesting that every single amiga guy thinks that one has to be totally mad to code intel asm... Before 1995, most pc demos were pure asm too. The only serious drawback is the lack of registers. On the other hand, the funky intel instruction set allows some very serious dirty tricks in, say 256b intros :) [really useful, isn't it? :))]
Additional the declaration of binary,hex or decimal values is more comfortable, because I'd rather write $ff than 0xff.
Pardon sir?? What the hell this has to do with the type of processor you are working on???! For example I always wrote 0ffh...
It's kinda interesting that every single amiga guy thinks that one has to be totally mad to code intel asm... Before 1995, most pc demos were pure asm too. The only serious drawback is the lack of registers. On the other hand, the funky intel instruction set allows some very serious dirty tricks in, say 256b intros :) [really useful, isn't it? :))]
Additional the declaration of binary,hex or decimal values is more comfortable, because I'd rather write $ff than 0xff.
Pardon sir?? What the hell this has to do with the type of processor you are working on???! For example I always wrote 0ffh...
Quote:
Before 1995, most pc demos were pure asm too.
Apart for some exceptions, dos demos sucked very badly anyway & the real mode was a pain in the ass to operate, etc.
Quote:
On the other hand, the funky intel instruction set allows some very serious dirty tricks in, say 256b intros :) [really useful, isn't it? :))]
256b are more made possible because com files have no file structure & intel instructions are coded on bytes basis. Also Intel's fpu instructions scheme is a disaster (notably compared to motorala's one)
More generally, the pc architecture is the worst thing that could have happened to the micro computers history.
But what's done is done.
The 64bits processors will hopefully bring some refreshments.
x86 is indeed a huge patchwork, but this has lead to one very positive thing; good optimizing compilers. and let's face it;
"compilers produce better assembly-code in milliseconds than humans does in hours" -- chaos/fr.
"compilers produce better assembly-code in milliseconds than humans does in hours" -- chaos/fr.
This is a long running story & i have had a lot of arguments with some called "asm gurus" about this topic, personally i only use asm for size optimizing.
I know some people able to produce faster code than any compilers out there but in the end such stunts are a waste of time & totally out of question for any descent sized project (even a 64k intro).
I know some people able to produce faster code than any compilers out there but in the end such stunts are a waste of time & totally out of question for any descent sized project (even a 64k intro).
blala:
sorry Sir, that's what I wanted to add but didn't want to make it longer ... I know hex declaration is with an "h" at the end. Nevertheless I'll never write an x86 mnemonic 'cause it's all too messy for my point o' view
sorry Sir, that's what I wanted to add but didn't want to make it longer ... I know hex declaration is with an "h" at the end. Nevertheless I'll never write an x86 mnemonic 'cause it's all too messy for my point o' view
Impressive that many of those big Amiga demos still contain enough or almost 100% assembly!
>if you're going to code gp32, you'll definately need to learn ARM assembler ;)
I don't think so. The machine is quite powerfull and I've tested to output some classic 320*240 effects. At the beginning I got 23fps and quite dissapointed, but then I found out that for some reason when the pointer to the videobuffer is global, speed goes too low. Defining it inside the subroutine of the effect, it gave out 83fps which is kool! Just a quick C port of the infamous plasma ;)
The only thing that I didn't liked is that without coding asm I don't know what happens in the memory really, as this strange slowdown with the global pointer. Defining my other variables and tables inside the main loop didn't had any change in speed though ;P And then I have to make various tests to be sure that I don't loose speed for reasons I don't know..
Then I was thinking what happens with the GBA. One summer years ago I fiddled with a tutorial about ARM assembly in the GBA for 3 days. I did a few stuff in the emulator, then because of other projects I left it. If I will try something in the GBA, I still consider ARM assembly for this because it's rather much slower than GP32. However, I have heard that demos like Phloam were coded purely in C!
Or is baardei really coded in ARM? That would be impressive :)
p.s. Now I went a bit into C, I know what I was loosing! Every machine has a C compiler out there and if the machine is powerfull enough I can just port effects easilly from my older sources (Call me lazy :). That's what I personally like. However, I still prefer assembly for slow machines or size optimizing. I don't know, perhaps I will still give the C compiler a try in GBA. Perhaps some modern effects will still need a little asm speed up even in machines like GP32..
>if you're going to code gp32, you'll definately need to learn ARM assembler ;)
I don't think so. The machine is quite powerfull and I've tested to output some classic 320*240 effects. At the beginning I got 23fps and quite dissapointed, but then I found out that for some reason when the pointer to the videobuffer is global, speed goes too low. Defining it inside the subroutine of the effect, it gave out 83fps which is kool! Just a quick C port of the infamous plasma ;)
The only thing that I didn't liked is that without coding asm I don't know what happens in the memory really, as this strange slowdown with the global pointer. Defining my other variables and tables inside the main loop didn't had any change in speed though ;P And then I have to make various tests to be sure that I don't loose speed for reasons I don't know..
Then I was thinking what happens with the GBA. One summer years ago I fiddled with a tutorial about ARM assembly in the GBA for 3 days. I did a few stuff in the emulator, then because of other projects I left it. If I will try something in the GBA, I still consider ARM assembly for this because it's rather much slower than GP32. However, I have heard that demos like Phloam were coded purely in C!
Or is baardei really coded in ARM? That would be impressive :)
p.s. Now I went a bit into C, I know what I was loosing! Every machine has a C compiler out there and if the machine is powerfull enough I can just port effects easilly from my older sources (Call me lazy :). That's what I personally like. However, I still prefer assembly for slow machines or size optimizing. I don't know, perhaps I will still give the C compiler a try in GBA. Perhaps some modern effects will still need a little asm speed up even in machines like GP32..
Oh and the floating point functions in GP32 are still extremely slow. I have to use fixed point..
Other than that,. to the other answers.
Yes, I do hate X86 for some stuff and I don't dare to touch FPU, but wouldn't that hard if someone gets used to it. It is not easy for me to get used in 68000, some things are the other way around, but there are a lot of registers and it is something new for me.
And don't say that PC demos sucked (in terms of coding), I have seen a lot of impressive stuff and one summer day I tried to code and optimize something in my old 386 and I have seen how hard it is to get something fast, then I wondered how the hell can they do it? I see effects in 286-386 still running at full frame rate in my old PCs with those slow gfx cards doesn't normally allow me, there are a lot of ModeX trickery in many of them, even the 486 had impressive 3d code later the demos also focused a bit more on design. Well,. at least they didn't have the same kind of design as the Amiga, but they were doing impressive things for the hardware and that is what counts!
Other than that,. to the other answers.
Yes, I do hate X86 for some stuff and I don't dare to touch FPU, but wouldn't that hard if someone gets used to it. It is not easy for me to get used in 68000, some things are the other way around, but there are a lot of registers and it is something new for me.
And don't say that PC demos sucked (in terms of coding), I have seen a lot of impressive stuff and one summer day I tried to code and optimize something in my old 386 and I have seen how hard it is to get something fast, then I wondered how the hell can they do it? I see effects in 286-386 still running at full frame rate in my old PCs with those slow gfx cards doesn't normally allow me, there are a lot of ModeX trickery in many of them, even the 486 had impressive 3d code later the demos also focused a bit more on design. Well,. at least they didn't have the same kind of design as the Amiga, but they were doing impressive things for the hardware and that is what counts!
Oh yes, you are right. My english suck when I am writting fast, in the anxiety of paying more for the stupid net cafe that has a higher price than in the older days ;P
TBL use Visual Studio on Peezee and have integrated at least the compiler. Don't remember if they had a debugger integrated yet. Then they run everything on WinUAE until party time. Only in the end they try it on an actual Amiga. It doesn't always work out ... Ocean Machine, winner at BP'05, had this problem---only works on some HW Amigas.
Kalms commenting Ocean Machine:
"(...) while most of the demosystem has been ported to build as a native Win32 application, some major parts are still missing. The sound decoding/mixing and the rasterizer backends contain a fair bit 680x0 assembly and there are no C versions of those piceces of code. Additionally, there is usually a bit of new assembly code for each part in the demo (usually some sort of image compositing or postprocessing filter). Making a working, native Win32 build out of the demo is thus not as easy as pressing a button yet. Making a video is easier and more cross-platform compatible, and our current opinion is that the visual result of a 640x400x25fps video is good enough."
"(...) while most of the demosystem has been ported to build as a native Win32 application, some major parts are still missing. The sound decoding/mixing and the rasterizer backends contain a fair bit 680x0 assembly and there are no C versions of those piceces of code. Additionally, there is usually a bit of new assembly code for each part in the demo (usually some sort of image compositing or postprocessing filter). Making a working, native Win32 build out of the demo is thus not as easy as pressing a button yet. Making a video is easier and more cross-platform compatible, and our current opinion is that the visual result of a 640x400x25fps video is good enough."
Asm coding used to be kind of fun, but once you understand that it is not magic, then better not waste any more time using it really. unless you really need to know exactly what is going on somewhere. Good optimizing compilers are not your enemies, they are your friends. When the machinelabour is done by a machine you can focus on being creative and getting dirty with some maths or something instead.
> Oh and the floating point functions in GP32 are still extremely slow. I have to use fixed point..
Guess why...the GP32 doesn't have an FPU :P
Guess why...the GP32 doesn't have an FPU :P
Yep. I was dissatisfied by the slow fpu emulation. I tried for example to precalculate three sine tables of 2048 values each, and that took about 4 seconds iirc! I think I'll even have to fit some of my precalculated tables inside the code instead, cause I hate long precalc times ;P
optimus: yeah, just precalc them and include the tables. I guess that was the standard way in the pre-fpu times (at least we usually did that, if my memory does not trick me :)
The other way is to use an approximation (say, taylor series, whatever) for the first quarter (0..Pi/2), code it using fixed point, and generate the rest by mirroring this (you can't generate the whole 0..2Pi interval directly because approximations tend to be very inaccurate as you go away from the starting point, zero in this case)
The other way is to use an approximation (say, taylor series, whatever) for the first quarter (0..Pi/2), code it using fixed point, and generate the rest by mirroring this (you can't generate the whole 0..2Pi interval directly because approximations tend to be very inaccurate as you go away from the starting point, zero in this case)
Nice overview on fixed point sine generators:
http://membres.lycos.fr/amycoders/tutorials/sintables.html
http://membres.lycos.fr/amycoders/tutorials/sintables.html
Why are there not many tiny intros on Amiga btw? I watched five 512byters and most of them sucked ;P
Nice tuturials btw :)
But then I find on the site, some compos for tiny stuff that seem to be better ;)
Still,. why aren't tiny intros not so popular in Amiga?
Still,. why aren't tiny intros not so popular in Amiga?
There are even speedoptimizing compos. WOOT!!!
there's been a sort of 4k war for some time now, but nothing under 4k..
Optimus: the reason tiny intros arent very popular on amiga is simply because the 7-8 active amiga coders left in the world (incredibly enough) have enough of a life to stay away from useless tiny-intro-bullshit. (Probably the only stupid thing we're not into...)
100% asm forever! Yes, I'm another moron, I know. ;)
