Can you be 'too old' to start to learn programming?

[Mrs Beanbag]

Originally Posted by Hewitson

I guess it's just a HUGE coincedence that the best software on the Amiga is done in asm then.

Boy were they wasting their time writing the Amiga's operating system in BCPL/C, that was never going to work.

Yes if you want to write something as fast as possible, asm is the natural choice. But there is really nothing wrong with writing in C for, for instance, productivity software, or games with less focus on fast action.

[AF2013]

There is so many Programming language out there!

Free one like

Blitz 3D
Blitz Plus
FreeBasic(bit more advance!)
GLbasic
NAALAA 6(It got tilemap build in to design own plaform game and it also got own doom build in that if you want to design it)


For Old school programming language like

Amos Pro(I love them)
Blitz 2.1
Amiga C
Turbo C (Yup, it is work on Windows 8.1...just make sure you got Dosbox installed in! You can create own Graphics)

Right now, Number one programming langauge is C believe it or not!

You can check out all the Basic programming langauge right here

http://basic.mindteq.com/index.php?i=popular

[Thorham]

Originally Posted by Hewitson

I guess it's just a HUGE coincedence that the best software on the Amiga is done in asm then.

Yeah, I'm sure that all the best productivity software on the Amiga was written in assembly language

[Nekoniaow]

Originally Posted by Hewitson

I guess it's just a HUGE coincedence that the best software on the Amiga is done in asm then.

As others mentioned that is likely true only for games.
Few people would use assembly to write a very large software which needs to be maintained and evolved over time, which is the case for most productivity programs.

Moreover, yes, it is indeed a coincidence.
The Amiga arrived a bit before the beginning of the period when games coders started the transition between assembly and C.

For 8 bits computers there was no way out of assembly, the CPUs were so limited that you had to crank out every single cycle out of the machine to get decent results. The Amiga is at least one order of magnitude faster than the fastest 8 bit home computers of that time and allows for much more latitude in language choice but alas the inertia of the existing pool of coders meant that most early games were written in 68k assembly. So necessarily most good games would be too. The causal effect is the reverse one.

Dungeon Master is 95% C (if not 100) and it's a fantastic game. Sure it could be a bit smoother at times but most of the time this is not necessary. Writing it in C gave the coders way more time to concentrate on gameplay and the ergonomics of the UI and the game is a textbook example of good user experience design. This couldn't have been done using assembly: modifications of the control flow and/or data structures takes way too much time, in C it's much easier.
It's pretty clear that this was an advantage: when it arrived, there were no other games like it. RPGs were static ugly things with mostly 2D graphics and limited game world interaction but DM offered consistent and very sandboxy like interaction with the game objects: something that you get via C typing system and is doable but hard in assembly.

So yes, it's a coincidence: had the Amiga arrived 5 years later this would have been much different.

[Thorham]

Originally Posted by Nekoniaow

This couldn't have been done using assembly: modifications of the control flow and/or data structures takes way too much time

Nonsense. Absolute nonsense.

[Nekoniaow]

Originally Posted by Thorham

Nonsense. Absolute nonsense.

Re-reading I realized that I should have added "with the same amount of effort/time", without that my sentence is indeed very false. So I thank you for pointing this out.

However you are too harsh to conclude my sentence is nonsensical as I gave enough hints aside from that sentence to let understand that it's not what I meant especially when I add a little bit further "[...] is doable but hard in assembly."

Refactoring in C is an order of magnitude simpler, this makes an enormous difference. I love the 68k assembly language, it's well designed, the instruction set is much more harmonious than its contemporaries and I like using it when needed but the productivity it offers cannot be meaningfully compared to C. Only its efficiency/performance can.

When you refactor in C, you do not have to worry about:
- register re-assignment, re-use, trashing, etc. since you use variables
- data structure modifications: modifying a struct inside a struct inside a struct does not require any code to change, nor offsets to recompute, no indirections to update
- proper typing: variables and pointers are typed, no need to be careful about mistyping (well, less need), the compiler will tell you when you are mistaking an int for a pointer or if you are not using an indirection when one is needed or vice versa
- control flow changes: add conditions to an if/else or an additional embedded branch, change a loop from do/while to for...
- etc.

On a micro scale, these things are all perfectly doable in assembly. On a macro scale, they are terribly hard especially if you have tuned register allocation to minimize ram bandwidth: add a variable and you have to rethink several levels of functions.
This work is worth it on some parts of a program, but on the ones where you need high productivity and lots of rework the use of assembly is a drag. On DM they did an extensive amount of work on the user experience and there are very interesting interviews with Doug Bell where he explains that they iterated an enormous amount of times. Doing it in C rather than assembly gave them an enormous edge, it's undeniable.

Hope that was clearer this time. My apologies again for my original incorrect blanket statement.

Edit: Oh dear, and now I'm pushing us even more into Off topic territory. Sorry!

[Thorham]

Originally Posted by Nekoniaow

However you are too harsh

Yes, that was too harsh, sorry about that.

Originally Posted by Nekoniaow

- data structure modifications: modifying a struct inside a struct inside a struct does not require any code to change, nor offsets to recompute, no indirections to update

Absolutely not a problem if you use the rs directive or OS include macros.

Example:

    incdir  "asminc:"
    include "exec/types.i"

 STRUCTURE struct1,0
 ULONG struct1.foo
 ULONG struct1.bar
 LABEL sizeOf_struct1

 STRUCTURE struct2,0
 ULONG struct2.foo
 STRUCT struct2.struct1,sizeOf_struct1
 ULONG struct2.bar
 LABEL sizeOf_struct2

 STRUCTURE struct3,0
 ULONG struct3.foo
 STRUCT struct3.struct2,sizeOf_struct2
 ULONG struct3.bar
 LABEL sizeOf_struct3

a
    lea     data,a0 ; points to structure 3
    lea     struct3.struct2(a0),a1 ; points to structure 2 inside structure 3
    lea     struct2.struct1(a1),a2 ; points to structure 1 inside structure 2

    move.l  #"foo3",struct3.foo(a0)
    move.l  #"bar3",struct3.bar(a0)

    move.l  #"foo2",struct2.foo(a1)
    move.l  #"bar2",struct2.bar(a1)

    move.l  #"foo1",struct1.foo(a2)
    move.l  #"bar1",struct1.bar(a2)

    rts

data
    dcb.b   1024

As you can see, the assembler does all the work and allows the programmer to change anything they want. Works in any sane assembler. Don't EVER make structures in assembly language by using numerical values instead of names.

Originally Posted by Nekoniaow

On a macro scale, they are terribly hard

Wouldn't call it hard, just more time consuming and a potential pain in the back side. I don't think assembly language is really any harder than C, it's just more work to get things done, and requires more thought in order to keep things from turning into a mess.

[Hewitson]

I wasn't including the OS in that statement. I would have thought that was obvious.

As for productivity software, the best and most popular one has to be Protracker. And guess what that was written in?

How many of the best games are written in anything except asm? How many demos?

Of course anyone with half a brain cell knew exactly what I was trying to say by my previous post. Obviously you just felt like having an argument.

[StingRay]

Originally Posted by Nekoniaow

Moreover, yes, it is indeed a coincidence.

It isn't. Compiled code is much too slow on a plain 68000 A500 so if you want speed you go for asm, not necessarily 100% asm but all the speed-critical parts. Disassemble any compiled C code and you'll see what I mean.

Originally Posted by Nekoniaow

The Amiga arrived a bit before the beginning of the period when games coders started the transition between assembly and C.

Most Amiga games were coded in asm for reasons mentioned above. It was like this until C= (and hence the Amiga too) died. Action games = asm. Adventures/RPG's = C (or any other HLL).

[Nekoniaow]

Originally Posted by Thorham

As you can see, the assembler does all the work and allows the programmer to change anything they want. Works in any sane assembler. Don't EVER make structures in assembly language by using numerical values instead of names.

Damn, that is neat.
I had a feeling assemblers could have such a feature when I wrote that line but my memory of Devpac is a little hazy.

Wouldn't call it hard, just more time consuming and a potential pain in the back side. I don't think assembly language is really any harder than C, it's just more work to get things done, and requires more thought in order to keep things from turning into a mess.

Again, you are correct.
Hard is not the proper term, time consuming and tedious is more appropriate.
C being higher level (but I would not call it high level, to me it's a typed assembly with automatic register assignment) it lets you concentrate on your algorithms and architecture first which is what really matters if you want to produce a good game. When this is set in stone you can go for the kill and convert the critical path parts to assembly.

StingRay is correct that C compilers produce code that is quite less good (although this depends a lot on the scope and how you choose your C statements) than kitten written assembly but it is supremely easy to transform C to assembly once you have prototyped your gameplay and settled on the game features.
Speed is important and necessary but that's not the sole thing you want to tune in a game. Gameplay is the part you want to be able to quickly iterate on and modify constantly during development, optimizing can come later and is specific to lower level routines: no need to optimize code which runs one a frame and controls the character if on the other hand you have a bob drawing routine which is called thousands of times.
The former is best written in C for easy tuning and modifying, the latter of course should be assembly.

C and assembly are tools which serve different purposes. Both useful.

[Mrs Beanbag]

Originally Posted by Hewitson

Of course anyone with half a brain cell knew exactly what I was trying to say by my previous post. Obviously you just felt like having an argument.

Anyone with half a brain cell could have written it.

Of course it isn't entirely a coincidence that many of the best games were written in asm, because many of the best games are trying to get the most out of the hardware.

But to say that to learn anything else is a "waste of time" is just plain ignorant. In fact, i'd urge anyone to learn C before they touch asm for so many of the reasons brought out in these arguments. Asm code is very difficult to maintain if you write in a naive way. Writing in C makes you think in a more structured way, and then you can go back to Asm and impose the same standards of discipline on yourself. You can write Asm that looks a bit like something a good optimising compiler might produce--in fact with a sufficiently good style and use of macros, you can make it seem more like a higher-level language.

The Asm books i learnt from in the early days taught me some very bad habits, but coding professionally in C++ for a few years has completely changed my outlook.

[Thorham]

To Nekoniaow:

You have some good points. The only good reason to do everything in assembly language is because you enjoy programming in assembly language as a hobby. If not, then it's a waste of time and should be kept to a minimum.

[Lonewolf10]

Originally Posted by Nekoniaow

StingRay is correct that C compilers produce code that is quite less good (although this depends a lot on the scope and how you choose your C statements) than kitten written assembly but it is supremely easy to transform C to assembly once you have prototyped your gameplay and settled on the game features.

"kitten written assembly"???!!!

What do animals have to do with programming?


For what it's worth, when I write code in ASM now the first thing I do is write pseudo-notes before I start coding the main loop, or even some of the subroutines. For example:

;    / detect button press (Joystick or cursor keys) and set animation
;    / update UD sprite graphics
;    / move UD sprite
;    / limit movement based on level layout
;    / update enemy sprites
;       / generate random number and activate enemy accordingly:
;        / get time from registers
;        / get seed (time took user to press start on main menu)
;        / adjust time
;        / add seed to time
;

The /'s were originally -'s, but as each part is completed I change them to /'s. It makes it easy to see at a glance what still needs to be done

[Mrs Beanbag]

Originally Posted by Lonewolf10

"kitten written assembly"???!!!

oh yeah kittens love to help their owners do some work! don't believe me, google images "kitten on keyboard"

For what it's worth, when I write code in ASM now the first thing I do is write pseudo-notes before I start coding the main loop, or even some of the subroutines.

add it to this old thread!
http://eab.abime.net/showthread.php?t=71180

[AF2013]

How easy is to make Sprites on the screen in Devpac Assembler?

somethings like this

Assembler code of drawing Red dot screen ; This is Red dots on the screen
Assembler code of drawing Blue dot screen ; This is Blue dots on the screen

Because if I am doing write in Assembler then I always put commets next to it otherwise I going get lost in coding!

How you guys write assembler without commets next to it to know what is does or it is that bag of experience that help you along the way?

[Nekoniaow]

Originally Posted by Lonewolf10

"kitten written assembly"???!!!

What do animals have to do with programming?

I have a tendency to visualize coders as kittens, this seems to reduce the amount of murderous thoughts which pop to my mind when I read these creatures's code, at least at work.

For what it's worth, when I write code in ASM now the first thing I do is write pseudo-notes before I start coding the main loop, or even some of the subroutines. For example:
[...]
The /'s were originally -'s, but as each part is completed I change them to /'s. It makes it easy to see at a glance what still needs to be done

I like it. I tend to do something similar whenever I'm writing a large system but the more I code the more I want that general skeleton to be the actual program. Which is why I like Haskell because it's very close to allowing writing a pure declaration of intent and having it compile.

And apologies to the original poster. It looks like every thread I participate in ends up being wildly off-topic-ed.

[gimbal]

Originally Posted by Nekoniaow

And apologies to the original poster. It looks like every thread I participate in ends up being wildly off-topic-ed.

Its the EAB way, don't feel bad about that. The forum would be quite boring without some nice hefty discussions blowing in all directions I for one have been reading all these posts with great interest and the occasional pang of disgust - it makes you feel alive.

Originally Posted by Hewitson

If you want to code on the Amiga anything but assembly is a waste of time. Otherwise I personally wouldn't start with anything but C. Languages like perl and python may be simpler but their usability is very limited.

Python is the wrong language for the Amiga. But as far as its limit, you can use AmigaDOS and run the compiled EXE format.

import os
...
# Program in Python
...
# Compiled program (as in C language or other programming language which compiles code)
os.system("DH0:program.exe")
...
# Program in Python
...