Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
20 crawler(s) on-line.
 123 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 amigakit:  11 mins ago
 OneTimer1:  17 mins ago
 NutsAboutAmiga:  20 mins ago
 kolla:  33 mins ago
 Gunnar:  36 mins ago
 Comi:  1 hr 2 mins ago
 vox:  1 hr 48 mins ago
 zipper:  1 hr 51 mins ago
 BigD:  2 hrs 55 mins ago
 OlafS25:  2 hrs 57 mins ago

/  Forum Index
   /  Amiga General Chat
      /  Commodore Amiga Global Alliance
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 Next Page )
Poll : Commodore Amiga Global Alliance
Yes, I would Join! £30
Yes, for less
Maybe
No
Bad idea, I have a better one....
Pancakes!
 
PosterThread
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 6-Oct-2022 10:16:49
#521 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@gonegahgah

Quote:

gonegahgah wrote:
I'll have to get back on the "diamond problem" because I can't remember if I had an answer or not.


Well it depends on your language of choice as to how (or even if) this works, but the C++ allows a class to inherit multiple copies of some ancestral class.

Suppose you have class A, which is directly derived by B and C. For whatever reason (and there are good examples, it's not just hypothetical) you decide to create class D that inherits both B and C.

You have two choices:

1) Do nothing special. You now have two independently inherited copies of class A in any instance of D. Depicting horizontally left to right, you now have:


A - B
\
D
/
A - C


Any methods of B of C that you call that in turn refer to a method of A, will do so on the A in "their" path. If you want to refer to an inherited method or property of A from D, you have to explicitly resolve it, e.g. B::A::doThing() or C::A::doThing()

2) Declare A a "virtual" base class in D. This ensures that the representation of D contains only 1 copy of A, no matter how many times it indirectly inherits A through multiple (and even direct) inheritance:

B
/ \
A D
\ /
C


Any references to methods or properties of A from anywhere in this assemblage, whether it's from a method defined in B, C or D will all operate on the same copy of A.

Generally option 2 is what most people intuitively assume will happen in a multiple inheritance case, but it isn't.

Many of the more trivial usages of multiple inheritance can be solved in singular inheritance languages that support the use of traits for common code. It's a common criticism of MI that it's complex, counter intuitive and some of the use cases can be replaced by traits and interfaces.

Quote:
I was thinking that there may possibly need to be some sort of runtime class building if it is possible and worthwhile.


This is what design patterns like Factory Method, Abstract Factory and Builder are for. The example I gave where some concrete class is composed of a number of abstracted parts that are then "assembled to go" is the Builder pattern.

If you are unfamiliar with Design Patterns, I can't recommend the book by the "gang of four" strongly enough: Design Patterns


Quote:

Quote:
Usually for graphics you'd use them when setting up a transformation matrix of some kind to do the actual rotation on masses of points using basic multiply/accumulation operations. So a handful of calls to sine and cosine may result in the rotation of millions of vertices.

Cool. After you mention it that sounds very true. I'm looking to write some 4Dspace code one day eventually (5D if you count time as an equal partner). Maybe they should call it 4sD+1tD?


So, this is what "homogeneous coordinate systems" are for. You may have noticed, if you have done any 3D programming with OpenGL or similar API that the 3D coordinate systems have four dimensions already, e.g. a vector may be defined as { x, y, z, w } where w tends to be 1.0 or 0.0.

The reason for this is that they use matrices for the main operations on arrays of vectors, e.g. rotation, scaling, translation and even projection. The key benefit of matrices is that you can multiply a set of them together into one matrix that performs all the operations in the order they were multiplied together, in one step on any number of vectors.

If you used only a 3 dimensional coordinate as your vector, you end up needing a 3x3 transformation matrix due to the rules of matrix multiplication. A 3x3 matrix can encode rotation, scaling but it can't encode any translation. If you try to do it on paper, you'll realise this pretty quickly.

Including the w coordinate allows you to expand the matrix to 4x4 and that allows an extra column (or row, depending on the internals of how it's represented) in which the translation operations are ultimately encoded. The effect of this translation term is mediated by the w value by which it is multiplied.

So, any vector that has a w value of 1.0 will have that element added as the translation term to it's already rotated and scale x, y, z position. Any vector that has a w value of 0.0 will be left unaffected by the translation and only be affected by the scaling and rotation aspects.

Generally then, the vectors that describe the vertices of your model will have a w=1.0 so that they can be scaled, rotated and placed in whatever space we are working in, but the vertex normals for it will have w=0.0 as they are purely directional and don't need to be re-positioned during any transformation (they may need normalising again if they have been scaled, however).

So if you do create a higher dimensional game engine, just be sure to make sure you use a homogeneous coordinate system with an extra dimension.

Last edited by Karlos on 06-Oct-2022 at 10:35 AM.
Last edited by Karlos on 06-Oct-2022 at 10:24 AM.
Last edited by Karlos on 06-Oct-2022 at 10:21 AM.
Last edited by Karlos on 06-Oct-2022 at 10:18 AM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Commodore Amiga Global Alliance
Posted on 6-Oct-2022 19:32:17
#522 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote:
@gonegahgah

Quote:
Again a structure needs to be provided to allow the return of both the x and y values


Yes, but does need to be as parameter


struct xy
{
int,x,y;
};

struct xy func()
{
struct xy ret;
ret.x = 20;
ret.y = 40;
return ret;
}

void func2( struct xy &value )
{
if (ticks>20) { value.x =20; }
}


But passing the destination as reference, allows C++ not needing to move it from stack to the variable, theoretically. And what if you only need to change X, and not Y, is it a good idea to return x and y? most likely not.

This:


return ret;

looks strange/bad to me, since ret should be allocated on the stack. AFAIR. But I'm bit rusted...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Commodore Amiga Global Alliance
Posted on 6-Oct-2022 19:51:56
#523 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@bhabbott

Quote:

bhabbott wrote:
@cdimauro

Quote:

cdimauro wrote:
@bhabbott
Wrong: for the people which like it or NEED it (injuries? You don't know how the real world is).

Ludicrous argument. Manufacturers don't put automatic transmissions in their cars for people who have injuries. If you are so injured that you can't operate the controls then you shouldn't be driving.

Do you know that with an automatic gear you do NOT need one foot for driving?
Quote:
But you don't understand what I am saying. Many people today don't know how to drive a manual car, because they never had to.

Which might be a good thing.
Quote:
Similarly, many programmers can't write in C without making 'idiot' mistakes, because they never had to write much C code. And why should they? Just like modern cars are easier and safer to drive, so modern programming languages are easier to avoid making mistakes in - and that's a good thing.

Indeed. But do you know that even experienced C/C++ programmers... make mistakes?

Having experience / seniority doesn't automatically give you the patent to write code without bugs...
Quote:
Quote:
a very common logical fallacy. As usual, you show to lack elementary logic.

I'm perfectly able to switch from manual to automatic gear. So, definitely I'm not an idiot. Whereas you, for what you said yourself, are one (I'm just applying YOUR "logic").

It's not my logic. It's the logic of people who say only 'idiots' make mistakes in C.

And this logic is out of the real world: see above. Nobody is exempted from making mistakes...
Quote:
Quote:
Totally wrong: you don't know what you talk about.

Why don't you just talk about assembly, since it seems to be the only language where you have some rough knowledge?

Says the person who doesn't know what he is talking about.

I know it. See below!
Quote:
I've written plenty of code in C on the Amiga, PC (Win16 and Win32), and MCUs (my last work project used an Arduino which I programmed in pure C). I just aren't arrogant enough to say that I never make mistakes - in any language. Heck, I make mistakes in asm all the time!

Eh? You said that modern languages have all the safety features. Which is totally wrong, as I've said!
Quote:
Quote:
I've already said it, but you don't understand because you're a stubborn dumbass: framed on you asm-only parallel universe (your cave)...

My man-cave is only for retro computing, and even there it isn't all asm.

I don't know where people got the idea that I am asm-only and reject all other languages. But the mere suggestion that I might enjoy programming retro computers in asm triggers the evangelists, who must stamp out all traces of it wherever they see it!

Then we have news: you're not only bounded to asm...

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 6-Oct-2022 21:39:24
#524 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@cdimauro

Quote:

cdimauro wrote:

This:

return ret;

looks strange/bad to me, since ret should be allocated on the stack. AFAIR. But I'm bit rusted...


It's actually legal because the return is by value. When objects like this are returned by value, there are various ways by which copying the value can be avoided by a compiler. For example, allocating the return value in the caller's stack frame and generating code such that the function called is just "filling it in". Alternatively, small structures might be packed into a register.

Last edited by Karlos on 06-Oct-2022 at 10:42 PM.
Last edited by Karlos on 06-Oct-2022 at 09:40 PM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
matthey 
Re: Commodore Amiga Global Alliance
Posted on 7-Oct-2022 2:59:48
#525 ]
Super Member
Joined: 14-Mar-2007
Posts: 1968
From: Kansas

Karlos Quote:

It's actually legal because the return is by value. When objects like this are returned by value, there are various ways by which copying the value can be avoided by a compiler. For example, allocating the return value in the caller's stack frame and generating code such that the function called is just "filling it in". Alternatively, small structures might be packed into a register.


That would be some optimization for the compiler to pack x and y into the return register. First, x an y are ints which may be the size of a register and C only supports one return value. Second, the structure is defined, the x and y values placed in the structure and a pointer to the structure returned. Some newer architecture ABIs specify multiple return value registers but C doesn't allow it. The idea is that different compilers could compile different modules while maintaining compatibility. It's possible a cross module optimization could use another return register but I would be surprised to see it. Most likely, a function like that would just get inlined if possible and otherwise use a structure.

The C standards seem fine with just using structures in memory. There are only Sin() and Cos() fp math functions and no SinCos() function. The 6888x FPU has a FSINCOS instruction that returns both and it is much faster to compute both at the same time as suggested.

FSIN and FCOS 391 cycles
FSINCOS 451 cycles

I believe the bigger obstacle to return more values is that some architecture ABIs do not define registers for them. The C code is easy enough to write return(x,y) but what do compilers do with backends that do not support multiple return values. Is it the compiler's job to create a structure to return multiple return values?

A more common function returning 2 values is div()/ldiv()/lldiv() which returns the quotient and remainder in a structure.

https://en.cppreference.com/w/c/numeric/math/div

Several common architectures have division instructions which return the quot and rem at the same time so this is far from efficient. Trying to use this function directly so only a single division is performed for both quot and rem may end up with code that is worse than using '/' and '%' in C math equations. Just look at the disassembled output, if it is readable. Short assembly inlines can also provide what C standards can't sometimes, if the assembly code is readable again. On high end systems, you don't worry about tens of cycles here and there anyway. Amiga code is all headed to being emulated on these high end systems, right?

Last edited by matthey on 07-Oct-2022 at 03:29 PM.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Commodore Amiga Global Alliance
Posted on 7-Oct-2022 4:38:24
#526 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@Karlos: right. Thanks for recalling it.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 7-Oct-2022 6:44:57
#527 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@matthey

Returning small* structures and unions in a register has been supported by GCC for as long as I can remember. There's switches to explicitly turn it on or off. See the documentation for -fpcc-struct-return and -freg-struct-return which control this feature.

*Small obviously depends on the register size. 4 bytes for 32-bit systems, 8 for 64-bit

Quote:
Second, the structure is defined, the x and y values placed in the structure and a pointer to the structure returned


Wrong. That's absolutely what they don't so. Try it yourself to see why. You would be returning the address of on stack memory that has gone out of scope when the function returns. I think what you mean are what I said first, where the structure is allocated in the caller's stack frame and invisibly handed to the function call to be filled in.

Last edited by Karlos on 07-Oct-2022 at 06:49 AM.
Last edited by Karlos on 07-Oct-2022 at 06:45 AM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
matthey 
Re: Commodore Amiga Global Alliance
Posted on 7-Oct-2022 17:10:28
#528 ]
Super Member
Joined: 14-Mar-2007
Posts: 1968
From: Kansas

Karlos Quote:

Returning small* structures and unions in a register has been supported by GCC for as long as I can remember. There's switches to explicitly turn it on or off. See the documentation for -fpcc-struct-return and -freg-struct-return which control this feature.

*Small obviously depends on the register size. 4 bytes for 32-bit systems, 8 for 64-bit


There are still several reasons why an optimization that puts a small structure in a return register may not be worthwhile even if the data fits. Memory is byte addressable and registers usually are not (even CISC registers usually only allow addressing the least significant datatype of a partial register). This means that the upper data in a register may have to be masked and shifted out. If the structure is originally built in memory and then copied to the return register, this is an extra step over simply returning a pointer to the structure. Using more return registers would often be more efficient as the returned data doesn't have to be unpacked or copied back to memory from a structure placed in the return register like it is in memory.

Karlos Quote:

Wrong. That's absolutely what they don't so. Try it yourself to see why. You would be returning the address of on stack memory that has gone out of scope when the function returns. I think what you mean are what I said first, where the structure is allocated in the caller's stack frame and invisibly handed to the function call to be filled in.


Sheesh. Tough crowd. I didn't say the structure was defined and allocated inside the called function that returns a pointer to a structure. Yes, it needs to be defined and allocated outside of it so the structure pointed to by the return value survives on return. This is not necessary if the structure is returned in the return register but extra copying from a local structure that does disappear may be necessary. Multiple return registers could allow the data to be calculated and returned without using any structures. If the 68k could use D1 as a 2nd return value, D0=x and D1=y would work for ints (D2=z would not work though as it must be preserved on function calls). I don't know what the SysV 68k ABI says as I've never found a copy online and it is likely old and primitive anyway. The SysV PPC ABI gives 2 return value registers for integers.

SYSTEM V APPLICATION BINARY INTERFACE PowerPC Processor Supplement Quote:

Return Values

Functions shall return float or double values in f1, with float values rounded to single precision. Functions shall return values of type int, long, enum, short, and char, or a pointer to any type as unsigned or signed integers as appropriate, zero- or sign-extended to 32 bits if necessary, in r3. A structure or union whose size is less than or equal to 8 bytes shall be returned in r3 and r4, as if it were first stored in an 8-byte aligned memory area and then the low-addressed word were loaded into r3 and the high-addressed word into r4. Bits beyond the last member of the structure or union are not defined.

Values of type long long and unsigned long long, where supported, shall be returned with the lower addressed word in r3 and the higher in r4.

Values of type long double and structures or unions that do not meet the requirements for being returned in registers are returned in a storage buffer allocated by the caller. The address of this buffer is passed as a hidden argument in r3 as if it were the first argument, causing gr in the argument passing algorithm above to be initialized to 4 instead of 3.


The PPC ABI is complicated and difficult to understand but I believe it is trying to define 2 integer return registers where possible despite C only having one return variable. The int x and y returns in a structure should end up in r3 and r4 without requiring structure in a register unpacking which is often more expensive with RISC architectures. Whether the compiler is smart enough to just use r3 and r4 in the function without ever allocating or using a structure in memory, I don't know but it should be possible with this ABI. Is this easier than having multiple return values and registers in C? Not for the C programmer but maybe for the C compiler developers. I don't think extra return values would be too difficult to support for compilers. Global storage for extra return values that don't fit in return registers could be allocated although the overhead would be higher than returning a structure using local storage. Many architectures have at least one extra scratch register that could be used as a 2nd return value though. Some languages support a 2nd return value like ARexx as I recall.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 7-Oct-2022 18:50:01
#529 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@matthey

The point is, returning structures by value without having to endlessly copy the data between memory locations is a problem most compilers solved decades ago. Returning a reference to anything on your own stack frame, however, is as bad granola as it's ever been.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Nonefornow 
Re: Commodore Amiga Global Alliance
Posted on 7-Oct-2022 23:59:46
#530 ]
Regular Member
Joined: 29-Jul-2013
Posts: 339
From: Greater Los Angeles Area

Did I hear correctly?

It is now intended to be CAGA = Classic Amiga Global Alliance.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 8-Oct-2022 12:28:51
#531 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Nonefornow

No. It stands for Cantankerous Awld Gits Argue

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Bosanac 
Re: Commodore Amiga Global Alliance
Posted on 8-Oct-2022 18:05:41
#532 ]
Regular Member
Joined: 10-May-2022
Posts: 255
From: Unknown

@Karlos

Quote:
In a few decades, Rust will be just another systems level language, living alongside Go, C++ and even C and some other language will be vying to displace them all.


https://vlang.io/compare

One thing that Rust proponents do is fail to take money into account.

Retrain your entire dev team and then spending months rewriting your entire codebase costs a lot more than paying 30k for a decent SAST tool.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 8-Oct-2022 18:53:28
#533 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Bosanac

That is true. Add to it that Rust actually has quite a steep learning curve to master. Everyone is so in love with the fact it protects developers from the mundane (and I concede frustrating*) bugs but if they need that, then they are in for a shock if they actually want to become proficient in it.

* As for the frustrating bugs in say C and C++ code bases there's a thing enterprise companies can learn from the games industry. Use a good debugger and don't allow code to be merged into production until it's been ran in one! The lex Fridman interview with John Carmack is an eye opener in that regard. During development he ran almost everything in a debugger. My personal experience is that "enterprise" development tends towards practises that introduce defects regularly and rely on testsrs, unit tests and CI to catch. Which is helpful, if you have close to full coverage. Except that's rare and the constant drive for new features, slavish cargo cult approach to agile (as late adopters with only partial buy in) usually results in a constant source of defects, most of which are the "logical" kind and not the "we have an out of bounds index" kind.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Bosanac 
Re: Commodore Amiga Global Alliance
Posted on 8-Oct-2022 19:05:43
#534 ]
Regular Member
Joined: 10-May-2022
Posts: 255
From: Unknown

@Karlos

What does Carmack know?

Everyone knows that shit posting on obscure web forums is what makes one a high achiever lol

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Commodore Amiga Global Alliance
Posted on 8-Oct-2022 19:12:38
#535 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12795
From: Norway

@Karlos

My impression is most of problems with C is due to clib, and std functions, too many of these functions do not check buffer sizes, they tendency to expect buffers as input instead allocated buffers when needed. some clib functions was created when where slow computers (servers), with not a lot of memory, and computers where not connected to the internet.

Last edited by NutsAboutAmiga on 08-Oct-2022 at 07:17 PM.
Last edited by NutsAboutAmiga on 08-Oct-2022 at 07:15 PM.
Last edited by NutsAboutAmiga on 08-Oct-2022 at 07:13 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 8-Oct-2022 19:21:41
#536 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@NutsAboutAmiga

You should do as I say (and not as I do) and try to learn modern C++. I mean modern, e.g. C++20. And I mean learn. Not just assume you know it because you know C and and wrote a class or two in 1998 era C++.

You will be surprised at how far removed from those problems it has grown and how it's moved to stronger discipline, more compile time abstractions and so on. You rarely even see a naked pointer, let alone get to misuse one.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
BigD 
Re: Commodore Amiga Global Alliance
Posted on 8-Oct-2022 21:55:28
#537 ]
Elite Member
Joined: 11-Aug-2005
Posts: 7307
From: UK

@Bosanac

Quote:

Bosanac wrote:
@Karlos

What does Carmack know?

Everyone knows that shit posting on obscure web forums is what makes one a high achiever lol


Carmack knows nothing! He became a brainless zombie/denizen of hell like all the others after the portal was opened on Mars!

Last edited by BigD on 08-Oct-2022 at 09:57 PM.
Last edited by BigD on 08-Oct-2022 at 09:56 PM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

 Status: Offline
Profile     Report this post  
BigD 
Re: Commodore Amiga Global Alliance
Posted on 8-Oct-2022 21:59:59
#538 ]
Elite Member
Joined: 11-Aug-2005
Posts: 7307
From: UK

@Thread

Do we get a T-Shirt and a coupon as part of this CAGA initiative? I'd settle for an update on the ETA for Vultures to Vampires Vol.2! Should I have to pay for an update?

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

 Status: Offline
Profile     Report this post  
BigD 
Re: Commodore Amiga Global Alliance
Posted on 9-Oct-2022 11:09:40
#539 ]
Elite Member
Joined: 11-Aug-2005
Posts: 7307
From: UK

@Thread

Amazon says the release is now July 2023! However it still states it covers up until 2021 which is blatantly wrong since there is now a volume 3!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

 Status: Offline
Profile     Report this post  
MEGA_RJ_MICAL 
Re: Commodore Amiga Global Alliance
Posted on 12-Oct-2022 23:43:06
#540 ]
Super Member
Joined: 13-Dec-2019
Posts: 1200
From: AMIGAWORLD.NET WAS ORIGINALLY FOUNDED BY DAVID DOYLE

NOSTALGIC PADDING

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle