Beginner to Amiga coding.

[TroyWilkins]

Now, my next little project is to do the same as this old little BASIC program I did in Atari BASIC on the Atari 400, only in an Intuition window on the workbench screen. I'm thinking that using PolyDraw within a loop would be the best way to do this, with the window being a fixed size to begin with, then later adapt it to be re sizable and to clear itself when resized and then determine the internal size and draw it to suit the new window size.

[ Show youtube player ]

It's not much, and it's certainly no megademo, but it would be a start at getting comfortable.

[Thorham]

Originally Posted by TroyWilkins

It's not much, and it's certainly no megademo, but it would be a start at getting comfortable.

It's always best to start with simple things

When you have it running, post the code. Beginners tend to not use language features properly, and we can help with that.

Also, don't let your mind be polluted by people telling you that goto is evil, because it has it's uses in C.

[Daedalus]

Funny, I was just writing an article about an introduction to programming and was talking about Goto. It's certainly not evil, but I would say that 90% of the time there's a better way of doing it. That remaining 10% though? Absolutely, go for it. Sometimes it's the simplest, most efficient way of doing things. The important thing is to know what's best for a particular situation.

Edit: Oh, and nice work on the Atari! I used an 800XL for years, that blue screen and keyboard noise instantly brings me back and now I've got a craving for an Atari emulator...

[TroyWilkins]

Originally Posted by Thorham

It's always best to start with simple things

When you have it running, post the code. Beginners tend to not use language features properly, and we can help with that.

Also, don't let your mind be polluted by people telling you that goto is evil, because it has it's uses in C.

No worries, will do! And I didn't realise there was even a goto equivalent in C?!?

Originally Posted by Daedalus

Funny, I was just writing an article about an introduction to programming and was talking about Goto. It's certainly not evil, but I would say that 90% of the time there's a better way of doing it. That remaining 10% though? Absolutely, go for it. Sometimes it's the simplest, most efficient way of doing things. The important thing is to know what's best for a particular situation.

Edit: Oh, and nice work on the Atari! I used an 800XL for years, that blue screen and keyboard noise instantly brings me back and now I've got a craving for an Atari emulator...

I think part of the reason it got/gets used so much in BASIC is that often it's the simplest, easiest way to achieve something, particularly in older dialects where there often doesn't seem to be any viable alternative. I mean, in the example Atari BASIC code in my video, I use goto in the wait loops while waiting for a keypress. There may be an alternative that wouldn't use goto that I'm not aware of, but that works, is easy, quick and effective in that use scenario. Of course, I believe there are better alternatives in later versions of BASIC, but I think the problem is people like me who only ever really coded in dialects of BASIC that didn't have these alternatives, who then wind up using the same sort of code to do things that can be done in better ways in later languages.

Oh, and thank you about my little program on the Atari, I'm sure it could be written better, but it was just a quick thing I belted out in an emulator - I had to look up the exact syntax for the setcolor and drawto commands, as I didn't remember them exactly after all these years, and I stole the turning off DMA trick from another code listing I found online, but other than that, it was all my own crappy work belted out in maybe an hour, just to scratch the itch I had for doing some quick and dirty programming, and to show the missus and kids one of the things I used to do on computers before the internet, hahaha.

I figure adapting it to run in C and run within a window, using the system to draw it, should help me not only understand C better, but also help adapt my way of thinking to the new language. Also, I have to admit to being curious to see how much faster it can do it on an A600 when compared to on the old Atari 8 bit, which as I'm sure you know, didn't exactly have a fast version of BASIC.

[Thorham]

Originally Posted by Daedalus

It's certainly not evil, but I would say that 90% of the time there's a better way of doing it.

Indeed

Originally Posted by TroyWilkins

I didn't realise there was even a goto equivalent in C?!?

It's useful for exception handling and breaking out of nested loops. Keeps you from having to write annoying code. There are probably some other minor uses that occur (very) infrequently.

[Zetr0]

Originally Posted by Thorham

Also, don't let your mind be polluted by people telling you that goto is evil, because it has it's uses in C.

Unless you are doing in-line assembly then "goto" should not ever be used as it breaks the methodology in 'C' and C++.

Its uses are not only limited but it better expressed without them.

Originally Posted by Daedalus

Funny, I was just writing an article about an introduction to programming and was talking about Goto. It's certainly not evil, but I would say that 90% of the time there's a better way of doing it. That remaining 10% though? Absolutely, go for it. Sometimes it's the simplest, most efficient way of doing things. The important thing is to know what's best for a particular situation.

I would say that there is 100% better way than any use of goto's - they are an inherently bad idea in a procedural language. if anything it is anachronistic thinking in what is essentially a modern language.

Originally Posted by TroyWilkins

No worries, will do! And I didn't realise there was even a goto equivalent in C?!?

There isn't, don't use it

Originally Posted by TroyWilkins

I figure adapting it to run in C and run within a window, using the system to draw it, should help me not only understand C better, but also help adapt my way of thinking to the new language. Also, I have to admit to being curious to see how much faster it can do it on an A600 when compared to on the old Atari 8 bit, which as I'm sure you know, didn't exactly have a fast version of BASIC.

This is a great place to start - I will dig up some links / reading material for you on drawing to the Amiga Screen and throwing bitmaps at it!-

[TroyWilkins]

Originally Posted by Zetr0

This is a great place to start - I will dig up some links / reading material for you on drawing to the Amiga Screen and throwing bitmaps at it!-

Ohhh, thank you, I would really appreciate that very much my good man, thank you!

I've fiddled with the code I found here, made a few changes: http://amigacoder.x10.mx/tutorial/draw.html

And here is a link to what I got up and running (yeah, there is a bug in it when you initially start drawing, as I have not set X_coord and Y_coord to have any initial values, but for learning purposes it does the job): https://dl.dropboxusercontent.com/u/22028650/drawdemo.c

From what I've read (on http://wiki.amigaos.net/wiki/Graphic...Single_Command), to draw the squares required for my little pattern drawing program, PolyDraw with an appropriately setup array, with the array being altered during the main loop after each draw, looks to me to be the best method, not only for achieving my goal, but for enabling it to be flexable enough to allow changes to the window size to be taken into consideration later once I have this running the way I want, while helping me become more comfortable with the use and manipulation of arrays in C. After all, this journey is more about learning and getting comfortable, rather than the end product - after all, I freely admit that this will be completely pointless, but I'm enjoying the intellectual challenge.

[Thorham]

Originally Posted by Zetr0

There isn't, don't use it

[Daedalus]

Originally Posted by TroyWilkins

No worries, will do! And I didn't realise there was even a goto equivalent in C?!?

There's a version of Goto in pretty much every language, it just doesn't get used much because it's not good practice.

I think part of the reason it got/gets used so much in BASIC is that often it's the simplest, easiest way to achieve something, particularly in older dialects where there often doesn't seem to be any viable alternative.

Exactly. Old 8-bit BASICS generally didn't have any concept of procedures, and often didn't have while or until loops, switch/case constructs and so on, so Goto and Gosub were as good as it got. Modern BASICs and most other languages do have all those things, but the Goto hangover has been carried over by people remembering the old BASICs from their youth.

I mean, in the example Atari BASIC code in my video, I use goto in the wait loops while waiting for a keypress. There may be an alternative that wouldn't use goto that I'm not aware of, but that works, is easy, quick and effective in that use scenario.

Yeah, for situations like that there's not that much you can do, but it's not a big deal on a single-threaded, single-tasking machine like the 8-bits. If you did the same thing in an Amiga program, or on any multitasking system, you should be shot

Of course, I believe there are better alternatives in later versions of BASIC, but I think the problem is people like me who only ever really coded in dialects of BASIC that didn't have these alternatives, who then wind up using the same sort of code to do things that can be done in better ways in later languages.

Bingo

Oh, and thank you about my little program on the Atari, I'm sure it could be written better, but it was just a quick thing I belted out in an emulator - I had to look up the exact syntax for the setcolor and drawto commands, as I didn't remember them exactly after all these years, and I stole the turning off DMA trick from another code listing I found online, but other than that, it was all my own crappy work belted out in maybe an hour, just to scratch the itch I had for doing some quick and dirty programming, and to show the missus and kids one of the things I used to do on computers before the internet, hahaha.

Indeed, sometimes it's so good to scratch that itch! A year or two ago I dug out all my old Atari code cassettes and read the code off them. Ugh, it's hard to read these days, but I did manage to write a reasonable if basic Tron clone that I was glad I could recover.

I figure adapting it to run in C and run within a window, using the system to draw it, should help me not only understand C better, but also help adapt my way of thinking to the new language. Also, I have to admit to being curious to see how much faster it can do it on an A600 when compared to on the old Atari 8 bit, which as I'm sure you know, didn't exactly have a fast version of BASIC.

Absolutely, porting a known piece of code is a good way of learning, though as stated before, you should always look to convert to more modern methods and drop the Gotos while you're at it. The program should be many, many times faster on an A600 - you should be able to draw patterns like that many times a second in multiple colours, swapping bitmaps to your screen or window so that you don't see the drawing in action.

[Daedalus]

Originally Posted by Zetr0

I would say that there is 100% better way than any use of goto's - they are an inherently bad idea in a procedural language. if anything it is anachronistic thinking in what is essentially a modern language.

True, they don't fit very well in a procedural language, and yes, there is always another method available than using Goto, but sometimes - just sometimes, that alternative method is longer, slower and actually harder to follow. It can be considered a hack and impure and what not, but at the end of the day, it works well and provided you don't do anything that makes the code harder to follow or do terrible thing like jumping out of constructs, it won't cause you any problems.

[Zetr0]

@Thorham / Daedalus

The fact that this "goto" expression exists in 'C' / C++ proves the point that it it shouldn't - it is legacy "ancient" thinking, and using this expression is utterly pointless and should only exist in a limited stack environment- in over 27 years of C programming (16 of them in a commercial sense) I have never had to use them, even when I am proving a point about run-time-polymorphism - which you can do in C.

The only time I have seen "goto's" used is when a chap I worked with used "in line" assembly - and he used it this way because he couldn't be arsed to count in the program counter for his variables in his asm C wrapper functions.

I am pretty confident in saying if someone can show me a use of the "goto" statement in 'C' I could write it better / faster in a function (even recursively).

[Samurai_Crow]

Regarding goto, for exception handling look at setjmp.h in the runtimes for a better way to do it without goto. Regarding exiting loops, the exit command and continue command do just as well in most cases.

[Thorham]

Originally Posted by Zetr0

The fact that this "goto" expression exists in 'C' / C++ proves the point that it it shouldn't

What's that supposed to mean?

Originally Posted by Zetr0

- it is legacy "ancient" thinking, and using this expression is utterly pointless and should only exist in a limited stack environment-

No, it should absolutely be in there, and can be used to make code cleaner and more readable sometimes.

Originally Posted by Zetr0

in over 27 years of C programming (16 of them in a commercial sense) I have never had to use them

That's probably because you've always been convinced that they're bad for some reason.

Originally Posted by Zetr0

I am pretty confident in saying if someone can show me a use of the "goto" statement in 'C' I could write it better / faster in a function (even recursively).

Okay, how about breaking out of nested loops? Wait, please don't, I already know what that's going to look like

All this goto hate is just ridiculous. I've never, ever, seen any good arguments against goto at all.

Actually, I wish I hadn't brought it up

[haps]

Originally Posted by Thorham

All this goto hate is just ridiculous. I've never, ever, seen any good arguments against goto at all.

Exactly. They can be an elegant way to program exceptions in C. Check the linux or BSD kernel code and you will see this throughout.

All this 'anti-goto' nonsense is the result of fear mongering by Wirth and Dijkstra.

[TroyWilkins]

Oooookay, I think enough has been said about the merits (or lack thereof) of goto now...

I think I may have bitten off more than I can currently chew with regards to C, but in a way, that's intentional. I could easily convert that linedraw program from Atari basic to C if I was to use Move() and Draw() to replace plot and drawto, but that wouldn't really help advance my knowledge in the way that I am trying to do.

Also, I'm not entirely sure how to replicate a for/next/step 10 basic loop in C, all the examples I've found deal in increments of +1, or do I have to go about that a different way?

Ahh, I should have just googled this, t seems this may be a way:

int i;
for(i = 1; i < 10; i += 2)
  printf("%d\n", i);

I've run into multiple issues with regards to using PolyDraw instead of attempting to draw single lines, but I'm not going to give up yet. This is where I've bitten off more than I can chew, as I'm having trouble setting up an array, and then having trouble when it comes to using that array in the PolyDraw, but I'm sure I'll work it out on my own, which is the whole point of this exercise, and will bring the most enjoyment when I do work it out. In fact, I think I've worked out the biggest problem I'm having while writng this, so once this is posted I'll try writing out what I'm thinking should work and see if it works...

[nogginthenog]

Originally Posted by Thorham

All this goto hate is just ridiculous. I've never, ever, seen any good arguments against goto at all.

What about the 'goto fail' Apple SSL bug :-) Personally, I don't have a huge problem with goto.

if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

err = sslRawVerify(...);

[Zetr0]

@TroyWilkins

LOL indeed, goto's in 'C' generally cause a fuss - for the record I don't think there evil, just that they break the methodology of 'C' and is arguably only included as a legacy from other languages.

you can also write you your expression as such -

The For ( *declaration / initialization ; *condition ; *variable_change) { *statements }

for(int i = 1; i < 10; i +=2)
     printf("%d\n", i);

Notice how I declared the "int" inside the for() - this means the variable is created at the moment of the loop and then destroyed after. This saves space on limited systems. If I maybe so bold I use a naming convention of variables for loops and use human names, that way I know whom to blame when its not working - its a method of thinking lol.

Here is another loop type

The While ( condition ){ *statement } Loop

int i = 1;
while (i < 10 )
{
     i+=2;
     printf(%d\n", i );
}

And another loop type

Do { *statement } While ( *condition ) Loop

     int i = 1;
     do
     {
          printf(%d\n",i );
          i += 2;
     }while ( i < 10 );

The difference in these loops will come down to your expression of logic in a lot of ways -

The For Loop initializes what you want at the start of the loop, checks the condition, processes the statements and increments the loop counter - in the above case that is print i to the screen. it then checks condition and increments - this repeats until 'i' = 11 and prints to the screen - it then then stops as the condition of 'i' is ">10"

For - Expected output

1
3
5
7
9
11

The While Loop processes its loop slightly differently, it will process each line inside this loop "{" and "}" once it finds the "}" it then checks the condition of the loop " i < 10 " and proceeds to process each statement again until " i >= 10 "

While - Expected Output

1
3
5
7
9
11

The Do While Loop is interesting as it always processes your statements once before checking the condition of variables - so in the above case the output would be different as the condition check happens after the increment - such that -

Do While - Expected Output

1
3
5
7
9

Now you might be thinking I can move where the increment is place in the "Do While" loop - however -

     int i = 1;
     do
     {
           i += 2;
           printf("%d\n", i );
     }while ( i < 10 );

This will then output -

3,
5,
7,
9,
11

Personally I love 'C' and 'C++' - I used to lecture this at the local collage - if you stick with it - it will reward you =)

[TroyWilkins]

I've got this as the basis for the calculations for the points to put in the array that will be called:

for ( c = 0; c < 201; c +=10 ){
		PLo[0] = 0;
		PLo[1] = c;
		PLo[2] = 200 - c; 
		PLo[3] = 0;
		PLo[4] = 200; 
		PLo[5] = 200 - c;
		PLo[6] = c; 
		PLo[7] = 200;
		PLo[8] = 0; 
		PLo[9] = c;
		/* use PolyDraw(&rastPort, 5, PLo); */
	}

I hope I'm finally on the right track here, if I'm not, any hints or pointers (pardon the pun) would be appreciated.

[Zetr0]

@Thorham

You have made quite an assumption about my coding practices based on my dislike for "goto" statements in "C / C++", hardly seems fair

Originally Posted by Thorham

That's probably because you've always been convinced that they're bad for some reason.

I am convinced that they are bad, not because of what you think i think ( wow there is an inception moment) but because it breaks the methodology of 'C' and 'C++' - the concept is modular code that is only dependent on functions not line numbers as in the case of "goto's".

Originally Posted by Thorham

No, it should absolutely be in there, and can be used to make code cleaner and more readable sometimes.

If one needs "goto" statements to make ones code readable - then clearly something is wrong here -

Originally Posted by Thorham

Okay, how about breaking out of nested loops? Wait, please don't, I already know what that's going to look like

That sadly is another assumption, I would say if you need "goto's" to get out of nested "if" conditions, you logic needs to be better thought out as you are reliant on line numbers not logic to complete your output.

Originally Posted by Thorham

All this goto hate is just ridiculous. I've never, ever, seen any good arguments against goto at all.

Actually, I wish I hadn't brought it up

Hate is a very strong word sir, I try not to have any hate in my life as it holds you back and stops you from being a better person. Having or holding any "hate" can and will define you - I wouldn't want that for anyone, least of all for what is essentially depreciated syntax.

Personally I think it is great that you have "mentioned" it as it highlights the "more than one way to skin a cat" in C/C++ - it also echo's to what my lecture said way back in 1993/4 - "As long as it works, there's no such thing as bad code - only better code"

In my opinion (and it is just that, my opinion) 'C / C++' is a really beautiful language, it is a means of thought and more so a methodology of logic that is both elegant and expressive the use of a "goto" statement that is dependent on line number kinda fcuks that all up

I can spend days coding (and have at that) - in this time I lose the ability to formulate English, and it can take me a good hour not not sound like "Yoda" from Star Wars =)

[Zetr0]

Originally Posted by TroyWilkins

I've got this as the basis for the calculations for the points to put in the array that will be called:

for ( c = 0; c < 201; c +=10 ){
        PLo[0] = 0;
        PLo[1] = c;
        PLo[2] = 200 - c; 
        PLo[3] = 0;
        PLo[4] = 200; 
        PLo[5] = 200 - c;
        PLo[6] = c; 
        PLo[7] = 200;
        PLo[8] = 0; 
        PLo[9] = c;
        /* use PolyDraw(&rastPort, 5, PLo); */
    }

I hope I'm finally on the right track here, if I'm not, any hints or pointers (pardon the pun) would be appreciated.

How I would write this, as if I was explaining it to a student I would initially write is thus -

void main( void )
{
    int ppoints[ 9 ];
    
    ppoints[ 0 ] = 0;         // since these are assigns 
    ppoints[ 3 ] = 0;         // and do not change in the code
    ppoints[ 4 ] = 200;       // its worthless to repeat the assign
    ppoints[ 7 ] = 200;       // better to assign then first 
    ppoints[ 8 ] = 0;         // and take only those that change into the loop
                              // = 100 less commands ;)

    for (int candy=0 ; candy < 201; candy +=10 )
    {
        ppoints[ 1 ] = candy;
        ppoints[ 2 ] = (200 - candy);
        ppoints[ 5 ] = (200 - candy);
        ppoints[ 6 ] = candy;
        ppoints[ 9 ] = candy;
        PolyDraw( &rastPort, 5, ppoints);
    }
}

Have a look at that, obviously there are better / quicker ways - but since this is your first foray in C/C++ we should keep it simple to begin =)