pouët.net

ok, well. i do agree with you, i shouldnt said hard. it is easy once you understand what the asm-instructions do. still i dont know what every instruction do, only the basic ones. but it is in a sense so hardware specific that you have to know how the cpu works in order to get a broader grasp of what's going on. like when you move or pop things into an register etc. may be hard for a newcomer to understand where all these numbers go. but read, read read and read! lots of stuff, if you repetitive read the same thing over again you'll finally write some own assembly code (if that's the language you choose). i find it very usefull to read articles or books that have figures, uml-diagrams or some drawings that explains whats going on instead of just reading text. i buyed some c64-assembler books that i read and was really helpful for a start. some instructions there basically do the same thing as other cpu's. of course, its many ways to start off.

ok,

many thanks everyone for all your good advices.

i really think i'm gonna give a try to x86 assembler to understand all those proc/memory-things, it can't be a bad thing at all

in parallel to that i'll take a look at this processing langage, which seems indeed pretty good to understand some of the basics, and may begin to work with C in a few months

thanks for all the advices on pointers, it's much clear in my mind now, i'm gonna try to code some small thing with pointers during the week-end to practice with that =)

any recommendation on good websites/tutorials/books for all those advices ? (particularly for x86 asm)

1. Learn code
2. ...
3. PROFIT

ffs. don't go straight to the iron.

you'll instantly loose interest if you start out with assembler languages. it's not like they are overly complex, but a lot is based on facts and techniques from lessons learned.

i started out modifying qbasic games and went on to pascal over to assembler and finally to c/c++.

I'd say :

1) Start with something like qbasic, to learn basic concepts easily
2) Move on to assembly, because the language is dead simple (almost as simple as qbasic) and you will learn a lot about hardware, os, libs etc. which is the difficult part
3) Move on to a procedural language and master it
3bis) Move on to an OO language, forget what you learnt in 3) (for example C++ has NOTHING in common with C) and try to master it ;)
4) read, read READ a lot. Read articles, tutorials, algorithms, techniques, everything about programming. Just be curious.
5) Choose your favorite language, but always be curious, learn every languages that come in your sight, and master only one, but master it
6) HAVE FUN
7) MAKE DEMOS
8) HAVE FUN AGAIN (the most important part)

Basically what Gargaj said, and Rasmus, really. Just a different language proposed.

Learn Python (Dive into Python is a great book), make GUIs with wxWidgets. You can feed an OpenGL statemachine from it anytime, and you are learning to fly easily. Although Python is not the preferred choice of demomakers (exception: Die Ewigkeit schmerzt), it is a very clean language. And I think it would fit your background so you don't feel lost when you are just about to start.

I'd say:

1) MAKE DEMOS
2) ???
3) HAVE FUN

wha kusma said

stupid but good tip: think about what you are interested in coding, already know, and feel you would be capable of doing/coding with ease. then use a relative guestimate from that base and think of something similar but "twice" as hard. then go code it!

you will find that all the knowledge you lack reveals itself but will not be far beyond your reach and, with the internet, pertinent keyword searches will lead you to a linked breadcrumb trail of knowledge (Vannear Bush would be proud)

noname: no, make GUIs with Qt. wx is horrible :)

OMG, what have I done :)
It may be risky to begin with asm :)
But well!
You have to choose 16 or 32 bits ; 16 is DOS ; I think these programs don't even run on my windows 7.
32 bits is probably more simple and modern but you learn less about the inner workings of the machine, and you have to do some windows programming to get windows on screen etc ; and this window programming is another block on the road...and maybe a big one if you've never coded. However maybe you can just use examples and not care about it.

For this I'd recommend fasm : http://flatassembler.net/
It's not the most widely used but it's a jewel. Beware, different assemblers have different syntaxes... The tutos and sources you'll find have a high risk of being "slightly" incompatible...Most used is prolly masm/tasm, but I prefer nasm syntax.
I should add that all this I did in another life...quite some time ago. Dunno the state of things now.
I think it might be best to begin with non-windows programs that only write and read things from the console, or draw pixels to screen... But on windows you have to deal with windows and buttons...
I just scrolled some doc pages...really, it's maybe too much hassle for someone who begins :) . At least if you don't follow a tutorial. To say the truth, I learnt this when I was young and brave, I had a huge will to learn and appetite ; I don't think I would do it today. :)

you can fire up dosbox and code in asm there, or you can make an own usb-boot disc with dos installed, ive allready done that and it works in a way, except for that i think theres something wrong with my computer, because it starts rebooting on strange times. if you have like an old usb-stick that you never use, like a 1 GIG or 256 megabyte one. Ok, maybe this is the last option, but its really easy to make a usb-boot disc. Dosbox is not 100% bugfree, but you can learn alot by coding asm in it anyway.
as HelloWorld said, you'll have to learn about win messages and all that crap if you wanna code asm in windows. That's not a good idea. Learn 8086 asm first or something. enough rambling from me..

mmh indeed ASM is frightening a lil bit, but i don't wanna go "far" with this langage, maybe just learn the basics to understand how memory & processor are managed ?

i'm gonna try a few things and compare to see in which langage i'm the more comfortable with.

and



i like that :) i'm always doing like this when trying to code some php things for example. trying to code something basic, and when it works, trying to do something harder, and harder and harder, and add thing. and finally when everything is working, trying to do the same thing with more simple and logic code :p

Hi, I didn't read the whole thread so... Stuff might be mentioned already.

I guess one of the most important things if not the most important is patience.
Things need time - you don't understand everything at the first look - it's just normal.
Depending on what you want to do - at least basic vector math skills (vectors, matrices, homogeneous coordinates, trigonometry) are a must.
There are many really good books out there having a nice "math primer" in the first chapter.
IIRC the math primer of http://realtimecollisiondetection.net/ was really good. Seems they are having trouble with copyrights and they are not fast at fixing it HINT HINT HINT... https://groups.google.com/group/google-code-hosting/browse_thread/thread/2bbe515f22ba54cf.
Googlecode delivers.

Patience and many, many years of dedication. I used to be on the "us assembler/DOS/Amiga (latter not being me really) coders have a headstart on lowlevel" front but I guess young guys like Ferris kinda killed that idea.

So patience, dedication and: one step at a time. A big elephant seems hard to digest at first, but if you take one bite at a time, it becomes a finite task. Most of us who know a fair bit about coding spent a shitload of time, that's a fact. And that's why it's also usually a fairly well-paid job :)

hehe, i'll be patient for sure :) thanks for the hint (and thanks for the link las).

my main "fear" was the langage to choose and the "approach" i should have because i don't wanna do the same errors i did in the past, beeing "blocked" by a stupid chapter and stop learning because of that.

so that's why i needed advices to start again on good bases, i knew demoscene coders could give me good informations about it. thanks everyone

Learn by trial and error.

Indeed, learn by trial and er

If you want to learn BASIC, I recently translated my tutorial which I had written when I was 12 years old to the English language and updated it a bit (so that it now works with free BASIC interpreters for Windows available on the Internet): http://www.hugi.scene.org/adok/tutorials/cbasic-english.pdf

you wrote a 42 side long tutorial when you was 12? sick.

I'm not so much surprised about being 12 (I wrote an assembler/DOS tunnel tutorial at that age) but BASIC as a subject.. Why? :)

learning BASIC when you already know scripting languages is rather stupid, but I guess the purpose of the link wasn't to help as much as it was to say "look at my mensa-ass - I wrote a tutorial when I was 12. Worship and grant me free Lebensraum".

Good point Nico. Though I do think that most tutorials are written with at least a hint of self-gratification. But doing it on BASIC.. well.. you're supposed to learn that language at 7 or 8 :)

Come on, people.