Click Here
home features news forums classifieds faqs links search
6049 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.
 20 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 Rob:  14 mins ago
 Skateman:  17 mins ago
 Comi:  22 mins ago
 BigD:  36 mins ago
 Karlos:  41 mins ago
 AMIGASYSTEM:  56 mins ago
 MichaelMerkel:  58 mins ago
 zipper:  1 hr 3 mins ago
 dframeli:  1 hr 21 mins ago
 Seiya:  2 hrs ago

/  Forum Index
   /  Amiga Development
      /  Packed Versus Planar: FIGHT
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 | 33 | 34 | 35 | 36 | 37 Next Page )
PosterThread
Karlos 
Re: Packed Versus Planar: FIGHT
Posted on 8-Oct-2022 13:06:36
#501 ]
Elite Member
Joined: 24-Aug-2003
Posts: 3372
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Gunnar

Interesting.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Gunnar 
Re: Packed Versus Planar: FIGHT
Posted on 8-Oct-2022 14:13:22
#502 ]
Regular Member
Joined: 25-Sep-2022
Posts: 152
From: Unknown

Hello Karlos

Quote:

The idea is to go on to define sets of raster operations for each type bitmap and benchmark them. I propose the following initial set of primitives:

void SetPixel(uint32 x, uint32 y, uint8 pen)
uint8 GetPixel(uint32 x, uint32 y)
void DrawSpan(uint32 x, uint32 y, uint32 w, uint8 pen)
void DrawLine(uint32 x1, uint32 y1, uint32 y1, uint32 y2, uint8 pen)



Are these function really the most important?
What do you think, what percentage of Amiga depend on these functions?

 Status: Offline
Profile     Report this post  
Karlos 
Re: Packed Versus Planar: FIGHT
Posted on 8-Oct-2022 14:34:05
#503 ]
Elite Member
Joined: 24-Aug-2003
Posts: 3372
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Gunnar

Not especially, they were suggestions that I felt would quickly expose what I think the limitations of planar are, while equally showing which operations would be the broadly the same.

And if it's not obvious, I think setting and getting pixels will be the worst for planar, and as a consequence general line drawing.

By contrast, drawing horizontal spans should be much closer together in complexity since if they are wide enough, you are just filling sequential memory for both planar or chunky.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Massi 
Re: Packed Versus Planar: FIGHT
Posted on 8-Oct-2022 14:34:34
#504 ]
Cult Member
Joined: 2-Feb-2011
Posts: 627
From: Rome, Italy

@All

I am Italian and of the exact same age of Cesare.

For the sake of intellectual honesty, I do believe that Cesare participated to the development of the game Fighting Spirit, but very likely more in terms of ideas to the game engine rather then code. I doubt that the production code of the game contains code written by him because in this case he would have been credited at least as additional coding.

With regards to USA racing, it was advertised on the game magazines of the time as work in progress, it was interesting with excellent graphics. My personal feeling is that it was far from complete and I never ever saw a demo of it running on Amiga. One of the above magazines, The games machine, nowadays is archived online and it should be easy to find more info, if I have the time.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Packed Versus Planar: FIGHT
Posted on 8-Oct-2022 15:00:54
#505 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12379
From: Norway

@Gunnar

Quote:
and Atari formats.


but why use that when you have real chunky.

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

 Status: Offline
Profile     Report this post  
Gunnar 
Re: Packed Versus Planar: FIGHT
Posted on 8-Oct-2022 15:05:36
#506 ]
Regular Member
Joined: 25-Sep-2022
Posts: 152
From: Unknown

Ciao Massi,

Come stai?

Quote:

Massi wrote:
@All

I am Italian and of the exact same age of Cesare.

For the sake of intellectual honesty, I do believe that Cesare participated to the development of the game Fighting Spirit, but very likely more in terms of ideas to the game engine rather then code. I doubt that the production code of the game contains code written by him because in this case he would have been credited at least as additional coding.

With regards to USA racing, it was advertised on the game magazines of the time as work in progress, it was interesting with excellent graphics. My personal feeling is that it was far from complete and I never ever saw a demo of it running on Amiga. One of the above magazines, The games machine, nowadays is archived online and it should be easy to find more info, if I have the time.


Many thanks for your feedback.
What you say is 100% the same what I think.

Fake war time stories can be funny if a grandpa tells them to his grandson.
"Listen kid when I was here with Buffalo Bill, it was the two of us against a million indians"
But fake stories are less funny here.

Cesare nonsense talk like "To play PC game ports on Amiga you need little Endian modes"
this is all completely wrong, and claiming this shit does help no one here in the forum.


 Status: Offline
Profile     Report this post  
Gunnar 
Re: Packed Versus Planar: FIGHT
Posted on 8-Oct-2022 15:09:10
#507 ]
Regular Member
Joined: 25-Sep-2022
Posts: 152
From: Unknown

Hallo NutsAboutAmiga

Quote:

NutsAboutAmiga wrote:
@Gunnar

Quote:
and Atari formats.


but why use that when you have real chunky.


To run Atari OS and play old Atari games...

 Status: Offline
Profile     Report this post  
Karlos 
Re: Packed Versus Planar: FIGHT
Posted on 8-Oct-2022 15:09:43
#508 ]
Elite Member
Joined: 24-Aug-2003
Posts: 3372
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote:
@Gunnar

Quote:
and Atari formats.


but why use that when you have real chunky.


I can't speak for Gunnar but I'd say "because we could". There are so many "what if" scenarios that are fun to think about but equally, possible to test. What if arbitrary N-bit packed pixels actually existed? Would they have been better? Worse? What unique things might they be capable of? Sure, we can all just use an 8-bit chunky display. Where's the fun in that?

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
kolla 
Re: Packed Versus Planar: FIGHT
Posted on 8-Oct-2022 22:44:31
#509 ]
Elite Member
Joined: 20-Aug-2003
Posts: 2377
From: Trondheim, Norway

@Karlos

I just wish to see the ultimate AGA clone for animating with Deluxe Paint AGA :)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
Hammer 
Re: Packed Versus Planar: FIGHT
Posted on 8-Oct-2022 23:15:45
#510 ]
Elite Member
Joined: 9-Mar-2003
Posts: 4611
From: Australia

@Gunnar

Quote:

Gunnar wrote:
In my opinion:

The POWERPC is a very good CPU for its intended purpose.
The purpose of the POWER CPU was to do floating point number crunching.

The POWERPC was not designed to be an 68K replacement.
It was sold like this my Apple, but it was not designed like this.


I think, the 68K has a number of design strong points.

a) very powerful EA-mode / memory operations
b) very powerful instructions
c) very coder friendly, very easy to learn and to code
d) very compact code
e) Good integer performance


POWER/PC has disadvantages in all these areas.
a) Power has some EA modes, but as powerful as 68K
And of course POWER can work directly on memory.
And POWER can not use 32bit or 64bit Immediates.
b) the power of instruction set of POWER is actually good.
In my opinion the 68K has some advantages.
c) POWER is very difficult to code.
Its assembly very difficult to read. And programs need a lot instruction than on 68K
So the AMIGA spirit of assembly demo coding is gone on Power.
But POWER is also very difficult to code in other areas.
The weak memory model makes multi-threaded coding very difficult.
e) All RISC CPU have a major design disadvantages with Integer code.
Integer code often work on memory, and often uses immediate.
RISC CPU can not directly work on memory, and are very limited in using immediate.

Example:
ADDI.l #$123456,$mymemoryvariable

Even such simple 68K instructions are a challenge for all RISC CPUs.
The RISC does not support the immediate and needs extra instruction to construct it.
The RISC does not support the memory address and needs extra instruction to construct the pointer
The RISC can not directly work on memory so its to need to add a LOAD and a STORE instruction.
For a single simple 68K instruction the POWER often needs 5 instructions.
Its no secret that RISC are always on a disadvantage with integer code.
This is why INTEL kicks IBM ass in the integer field.



What I liked a lot about Amiga was the easy demo and game coding.
The Amiga had a very nice to code CPU.
The instruction set was powerful, and it was enjoyable to code the Amiga in assembly.
What I also love in AMIGA is the DMA based, clever chipset.
Which allowed the coder to do clever things and to do many things very efficiently.
DMA audio, Copper, Sprites, you know what mean
For me these things are very cool on Amiga!


And for me the PowerPC machines miss all what I liked at the Amiga.
They lack the Amiga chipset that I liked, they are difficult to code and the cool Amiga game, demo coding fun is totally gone. The POWER CPU is really a pain to code in ASM.
I speak from experience have written huge libraries in PPC-assembly and was a pain on POWER.


I think it depends what you want.
If you like to code in assembly - then 68K rulez
If you understand how elegant the AMIGA chipset was.
And if you enjoy the elegant idea of the AMIGA design ... then you will miss this beauty on a PC hardware.

If not are not interested in assembly coding, and not see the beauty of the Amiga design - as I do - then you maybe find these PPC good.

But I'm not here to judge. Each his own. Use what you like.

Stereotyping RISC CPUs has a disadvantage with integer code is not wise e.g. Apple's M1 (with 8 wide instruction issue decoders) has pretty good integer processing and gives Intel Golden Cove's six wide fused instruction issue + micro coding complex issue decoders a run for the money.




Due to Apple's Geekbench marketing, both Intel (Golden Cove) and AMD (Zen 4) have raced ahead on single-thread Geekbench 5.x benchmarks.

Last edited by Hammer on 08-Oct-2022 at 11:34 PM.
Last edited by Hammer on 08-Oct-2022 at 11:33 PM.
Last edited by Hammer on 08-Oct-2022 at 11:19 PM.
Last edited by Hammer on 08-Oct-2022 at 11:17 PM.

_________________
Ryzen 9 7900X, DDR5-6000 32 GB RAM, GeForce RTX 3080 Ti
Amiga 1200 (rev 1D1, KS 3.2, TF1260, 68060 @ 63 Mhz, 128 MB)
Amiga 500 (rev 6A, KS 3.2, PiStorm/RPi3a/Emu68)

 Status: Offline
Profile     Report this post  
Hammer 
Re: Packed Versus Planar: FIGHT
Posted on 9-Oct-2022 0:06:23
#511 ]
Elite Member
Joined: 9-Mar-2003
Posts: 4611
From: Australia

@Gunnar

Quote:

68K uses Bigendian format. Amiga memory layout is also Bigendian.
Copper list are in Bigendian, Amiga screenmodes are in Bigendian,Audio to play by PAULA the Amiga audio chip, is in Bigendian. Also our SAGA chunky modes are Bigendian.
PC use LittleEndian

I'm surprised that you do not know this.


FYI, Xbox 360's IBM PPE CPU and ATI Xenos GPU are in big-endian mode.

This is why Xbox One's backward compatibility with Xbox 360 requires converted Xbox 360 art assets to be downloaded into the Xbox One's mass storage device since Jaguar CPUs weren't powerful enough for real-time art asset conversion with DVD data storage magnitude.

ATI Xenos is the last major GPU design that operates in big-endian mode.

ATI Xenos was designed with pointer swapping capability with IBM PPE CPU before AMD's GCN's "Fusion" with X86 CPU marketing.

Xbox 360 emulator Xenia for Windows runs fine on recent desktop X86-64 CPUs and Vulkan-capable GPUs.

_________________
Ryzen 9 7900X, DDR5-6000 32 GB RAM, GeForce RTX 3080 Ti
Amiga 1200 (rev 1D1, KS 3.2, TF1260, 68060 @ 63 Mhz, 128 MB)
Amiga 500 (rev 6A, KS 3.2, PiStorm/RPi3a/Emu68)

 Status: Offline
Profile     Report this post  
Hammer 
Re: Packed Versus Planar: FIGHT
Posted on 9-Oct-2022 0:20:06
#512 ]
Elite Member
Joined: 9-Mar-2003
Posts: 4611
From: Australia

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote:
@Gunnar

Not sure why you insist on comparing your Vampire ageist a crippled computer, because that’s what the XE really is.

XE had lot of potential, you had 2 x memory banks, this could have given better performance, by interleaving the memory banks. it had AGP 2x, it could have given better performance as GPU can access system on its own (in theory). G4 has lots of L2 chance, on Sam460 that similar problems and the L2 is always off (but can be enabled, we know can have huge impact on speed it can have), I’m not sure what case on XE. A lot of XE features where never ever used, due to the “Artica S” chip.

I believe one of the issues with Artica S, was that did not report when the DMA was done, so need take that into account. (Should pretty easy to calculate however, do some time keeping.), anyhow via686b was also known as a problem chip in PC industry before the XE was released.

On paper the XE looks like it’s better than the Pegasus II, but in reality, the Pegasus II with its Marvel chipset always outperformed the XE, at similar clock frequencies.

Lett summarize:
Using 2 x memory sticks never worked reliable, it had issues with interrupts (often IRQ was disabled in drivers, using PIO4 mode), AGP never preformed to specifications, USB ports was f*cked, and L2 cache was most likely deactivated.

It's only a problem on certain VIA boards, the AMD 76x NB/VIASB hybrid did not suffer from the same problem.

Apollo Pro 133's KX-133A and VIA 686B combination issue.

The bug was uncovered by the German hardware site Au-Ja! It's not exactly a common problem: the date corruption affects large, 100MB and up file transfers between two hard drives connected to separate IDE channels exchanging the data by DMA. Having a Creative Labs Soundblaster Live card in place seems to exacerbate the problem.

VIA's BIOS fix works by adjusting a number of PCI settings, which, according to Tecchannel, suggests the problem is a result of competitive PCI access.

The short version is that the SB Live! causes audio distortion and data corruption on VIA North Bridge/686B setups. There were three fixes. The first was a PCI latency patch. The second was a revised 4-in-1. The third was a BIOS update. Any one of the three works.

Reference
https://arstechnica.com/civis/viewtopic.php?f=8&t=891583

PS; For AMD K7 CPUs, I dumped my VIA KTxxx chipsets for NVIDIA nForce 2 chipsets.

_________________
Ryzen 9 7900X, DDR5-6000 32 GB RAM, GeForce RTX 3080 Ti
Amiga 1200 (rev 1D1, KS 3.2, TF1260, 68060 @ 63 Mhz, 128 MB)
Amiga 500 (rev 6A, KS 3.2, PiStorm/RPi3a/Emu68)

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Packed Versus Planar: FIGHT
Posted on 9-Oct-2022 4:13:15
#513 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3097
From: Germany

@Karlos

Quote:

Karlos wrote:
@Gunnar

Quote:
What I liked a lot about Amiga was the easy demo and game coding.
The Amiga had a very nice to code CPU.
The instruction set was powerful, and it was enjoyable to code the Amiga in assembly.


This was a large part of the motivation behind MC64K.

I fully agree.

The same was for me and my C64K. And NEx64T has "inherited" a lot, despite it's a x86/x64 superextension.


@Hammer

Quote:

Hammer wrote:
@Gunnar

Stereotyping RISC CPUs has a disadvantage with integer code is not wise e.g. Apple's M1 (with 8 wide instruction issue decoders) has pretty good integer processing and gives Intel Golden Cove's six wide fused instruction issue + micro coding complex issue decoders a run for the money.

Highly questionable.

Plus, M1 got those results only because it uses A LOT of resource both at the micro-architecture and system (SoC) level: WAY MORE than Intel's Golden Cove and newcomes.

[... PICTURE REMOVED...

BTW, your pictures are almost always too big! Try to reduce them of upload them on some images hosts which offer resolution reduction and the possibility to zoom to the full size]

Quote:
Due to Apple's Geekbench marketing, both Intel (Golden Cove) and AMD (Zen 4) have raced ahead on single-thread Geekbench 5.x benchmarks.

Geekbench is pure sh*t, since it's a synthetic benchmark.

Real world applications (NOT using any hardware accelerations which are outside of a processor's core) should be used instead.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Packed Versus Planar: FIGHT
Posted on 9-Oct-2022 5:21:38
#514 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3097
From: Germany

@Gunnar

Quote:

Gunnar wrote:
Cesare Di Mauro,

Quote:

That's because nobody took care of proper conversions, like I've stated before.
So, the problem wasn't about the systems, which were perfectly able to run those games even in FullHD (and more) with much more FPS: it was about the developers which did a very bad job with the port


Thank you very much, for your wise words of the arm chair Amiga coder.

YOU are very and warmly welcome!
Quote:
OK you rant now how all game ports for OS4 suck?

I don't know, because I never stated something like.

I've only said a very elementary concept which even the average Joe should be able to understand: if there's a GPU on a system and I've to make a game or port it, then... I use it. Which is particularly true if the system has performance issues.

It shouldn't be difficult to get the concept, right?
Quote:
How much SCUMM sucks,

The problem with SCUMM (itself) is that it should run several games which have even very different assets, which sometimes aren't compatible with the host (GPU) system (so, they require conversions).

So, you need to have proper "frontends" that extract those assets and prepare them in a suitable format for the host system, so that the general backend (which uses DirectX/3D , OpenGL, Metal, ...) could fully hardware-accelerate their rendering.

You don't need to rewrite everything. The backend is already there and it's general and written just one time: it's a set of common APIs (which could be used by any other project like SCUMM).

The frontend requires a conversion phase for each game. But several games use similar assets, so a common frontend can be created for them.
Quote:
how much MAME sucks,

The problems with MAME is like with SCUMM, but greatly exacerbated, since it supports THOUSANDS of different systems.

It's possible, but requires a HUGE amount of work.

Last, but not really least, the MAME guys are obsessed over "perfect preservation", so they just use the CPU for everything because they want to be super-mega-hyper-fully accurate.

So, I don't see chances to have something like the above.
Quote:
that DOOM sucks,

I don't understand if you're a masochist and have pleasure on shooting yourself in the foot.

Anyway, you're served: https://doomwiki.org/wiki/Category:Source_ports

I think that Doom was one, if not The, mostly ported game ever. And of course there are people, mostly single guys, which had enhanced it, and some also have rewritten the graphic engine to use the graphic card instead of relying on the CPU to do everything.

The most notable example from this PoV:
https://doomwiki.org/wiki/GZDoom
https://doomwiki.org/wiki/GZDoom#Features

OpenGL renderer, allowing the following features:
Full 3D floors (including slopes)
Reflective floors
Dynamic lights, brightmaps, glowing flats, custom hardware shaders
Quake II and Half-Life-style skyboxes in addition to regular ZDoom skyboxes
Optional High-quality (HQnX) rescaling filters for graphics, sprites and textures
MD2, MD3 and DMD model support

When the QZDoom codebase was merged into GZDoom, the latter gained several new features developed by Magnus Norddahl (dpJudas) and Rachael Alexanderson (Eruanna). These include:

Polygonal, 3-point perspective truecolor software renderer (“Softpoly”)
Truecolor support for the classic 2-point renderer
Postprocessing framework (SSAO, bloom, blur, custom post process shaders, etc.)
Vulkan renderer backend
HDR monitor support
ZScript just-in-time compilation
Proper windowed mode support (i.e. you can freely resize the game window)
Correct ZDoom software light mode for the hardware renderer
High resolution correct version of the software fuzz, for both software and hardware renderers
Improved dynamic light math, shadowmaps and spotlights
Materials (Classic, normal and specular maps and PBR textures), but not environment maps


Gunnar, Gunnar, Gunner, ... let me quote YOU:

"I'm surprised that you continue to argue.
Do you really want to show all the world that you talk bullshit?
[...]
I'm surprised that you do not know this.
[...]
A game coder would know this.
[...]
You often talk about stuff that you have never done yourself,
[...]
and you make assumptions and claims based on information that you "assume" to be true.
[...]
And it regularly happens that you don't inform yourself properly
[...]
And then you "talk out of your ass"."




And since YOU said also this:

I said that AMMX is highly tuned for video and game operations.

doesn't it also apply to... rolling drum... a GPU / video card?

I want to see if you finally be able to give a single answer to the many questions that I've raised. Dreaming is cheap, but the reality is sad...
Quote:
that DIABLO sucks,

https://freeablo.org

So, I’ve gotten the main renderer ported to OpenGL instead of using SDL2
[...]
Why would you want this? OpenGL lets us use programmable shaders, so we can do fancy lighting effects, instead of just dumping images on top of each other.


But the best part I'll save for after: see below.
Quote:
that in fact all Amiga game ports are terrible because the coders did not rewrite the games from scratch - like a "proper coder" would do?

Who said that games necessarily need to be rewritten from scratch? Ah, yes: it was YOU! Gunnar said! Certainly NOT me.
Quote:
So all Amiga developer suck, right?
They all did a very bad job?

Look, the point is they did a job
Someone at least ported DIABLO to OS4.
Someone at least compiled SCUMM for OS4.

Sure, and that's OK: the product is available. But it could have been done MUCH better. See above.
Quote:
Cesare the arm chair expert who does nothing but posting in forums.

Guess what: YOU're also extensively writing in forums (much more on your) and on other places (Discord).
Quote:
He tells all Amiga developers which in opposite to him actually do something for OS4 for Amiga - that they suck?

I've told that ports could be much better: see above.

And to show how much better could be done, let me go back to Diablo and the mentioned freeablo:

As for optimisations, the big one was batching, thanks to @grantramsay for getting that started. For those of you who are not familiar with graphics APIs, fundamentally what you do is a: push vertex data onto GPU, and then b: issue commands to draw the vertices with a specific configuration (shader, blending, etc). Especially in older apis like opengl and Directx 11 and under, there is a large cost associated with issuing a new draw call, so if you can batch up items that use the same state configuration and issue fewer, but larger draw calls, that is a major performance win.

In the end, the system I implemented involves pre-loading all the assets in the game into a series of large atlas textures. Before, each game sprite was in a separate texture, so we had to bind the correct texture for each sprite before drawing. If you draw two textures in a row that share the same texture atlas however, since you don’t need to change the GPU state (the currently bound texture, in this case), you can batch them both into one draw. This way, you can accumulate a “batch” of draws as they come in, and only send them to the GPU for rendering when you get a new request which switches the texture.
[...]
In freeablo, what I did was, in the shader for drawing sprites, write the original index of the draw into the z-buffer (actually, a normalised value generated from the position). This means that we can use the z-buffer to sort the sprites in their original draw order, while issuing the actual draws in whatever order we want. As the sprites are drawn as textured quads, we had to take the alpha channel into account as well when writing the z-buffer (transparent pixels are effectively infinitely distant from the camera).

In the end, this whole process resulted in a framerate bump on my machine from somewhere around 50FPS to about 700. There is still low-hanging fruit (eg, the game tiles are diamonds, but we draw them with a non-rotated square, so we’re drawing a lot of useless transparent pixels), but for now I think that will do.


I think that it doesn't deserve further words, right? It should be clear enough...
Quote:

Gunnar wrote:
@cdimauro

Quote:

Whereas YOUR assumptions about kolla's systems are OK even if they were completely wrong?


Do you really call me out for misunderstanding an english word?

Well, one word could make a great difference. Like in this specific case.
Quote:
Kolla said: "I have an actual Vampire here"
I know the word "actual" under the meaning of "current, latest, newest"
The V4 family are the current systems, and the V2 are the old discontinued family.

If V4 are VAMPIREs why don't you call them with this name?

Igor is still using that name, right?
Quote:
Quote:

Care to show me which game have you developed for Amiga?

We just spoke about many of them.
Apollo-Crown, Dr-Apollo, I'm currently working on Apollo-X

Which aren't Amiga games. Vampire and V4 boards aren't Amigas.

Have you written a game for an Amiga OCS/ECS or AGA?
Quote:
And I participated in several. The port of Robin-Hood to MorphOS, does MorphOS count as Amiga?

MorphOS is clearly NOT an Amiga. It's not even an hardware system, rather just an o.s....

Gunnar, Gunnar, Gunnar... why you don't know elementary technical things? Bah...
Quote:

Gunnar wrote:
@cdimauro

Quote:

And nobody of them produced something comparable to Fightin' Spirit and USA Racing...


Where is "USA Racing".

On my hard drive: 23036 bytes ATM.
Quote:
Please give us the EXE, so that we can see what comparable to it is.

Well, no.

Actually I gave a complete set to Jeremy Reiner when he was working on his article:
https://arstechnica.com/gaming/2010/06/shadow-of-the-16-bit-beast-an-amiga-gaming-retrospective/2/
But he used nothing.

You can ask him to provide some screenshots or even make a video: he has my permission. But nothing else should be used for different reasons.
Quote:

Gunnar wrote:
Quote:

And nobody of them produced something comparable to Fightin' Spirit and USA Racing...


What do we know about "Fightin' Spirit"?
We know for sure that you were not the lead developer.
We know from you that many of your proposal for the game were rejected.

All correct 'til now.
Quote:
Cesare Di Mauro, do you take credit for your friends achievements?
Don't do this.

In fact I don't.

Why do you write lies, since you know NOTHING about Fightin' Spirit?
Quote:
I not try to take credit for "APOLLO-INVADER".
Arne did ask me a few times, and maybe 10% of the code in the game are mine.
But this game is not my achievement. Its Arne achievement he did the most.

Good. At least here seem to be honest. Maybe because he's your son.
Quote:
Cesare all we see that you pretend to know so much about Amiga coding.

Correct.
Quote:
And you pretend you would have done "very important code"
25 years ago in an Amiga game with your friends.

Correct again.
Quote:
Do you really think all forum readers here are stupid?

No, absolutely. I think that stupids are the ones that get cheated by your lies and believe you.
Quote:
Where are your demos?

I've already replied several times: do you have personal problems that prevents you to understand it?
Quote:
Where are the games that you did in the 25 years after?
Where is anything?

Irrelevant. Another logical fallacy, but we know that you're used to them. You luck elementary logic.

Anyway, what you did for the Amiga (A-MI-GA. And nothing else) in the last 25 years?
Quote:
Did you had an accident and lost your memory and all your programming knowledge?

Clearly no. Maybe you've problems understanding my technical writings: this could explain everything.

But you're free to prove me the contrary, eh! YOUR is the thesis and YOUR is the burden of proof.
Quote:
Why did you not do anything at all, in the last 25 years?

Irrelevant again. You're the king of logical fallacies.
Quote:
Do you really think, that we not all see through this?

What I see is the immense use of logical fallacies from you: do you think that people are interested on those?
Quote:
Cesare please stop pretending to be something which you are not.

Care to prove it? Just one time, eh! I'm still missing the first proof from you.

Don't delude your Minions: remember that you're their hero!

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Packed Versus Planar: FIGHT
Posted on 9-Oct-2022 5:26:46
#515 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3097
From: Germany

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote:
@cdimauro

[quote]Amiga with RTG and AmigaOnes supported little endian as data format. For obvious reasons.


its not by choice, its just they things are…
naturally some stuff is equally CPU intensive on BE as LE.
ARGB or BGRA if I do…

uint32 ARGB = A

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Packed Versus Planar: FIGHT
Posted on 9-Oct-2022 6:14:51
#516 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3097
From: Germany

@Massi

Quote:

Massi wrote:
@All

I am Italian and of the exact same age of Cesare.

For the sake of intellectual honesty, I do believe that Cesare participated to the development of the game Fighting Spirit, but very likely more in terms of ideas to the game engine rather then code. I doubt that the production code of the game contains code written by him

I haven't disassembled the final code, but I think that mine is still there.

I did two major contributes to the graphic engine.

The first was to port a technique used on USA Racing and which allowed to reduce the double buffers to around half their sizes.
In the beginning Perpetual Craze and then Fightin' Spirit used three 608x256x64 colors screens: one for keeping the foreground and two for the double buffering. So, a lot of space was used.
With my trick we gained around 1/3 of (precious) chip mem. This code should still be there, because there was no reason to change it.

The second was the most important contribute.
In the very beginning Perpetual Craze/Fightin' Spirit was running at 25FPS but with limited space for the characters. So, they lacked many animations.
Then a trick was introduced by the music artist (which was another very talented coder!), which allowed to roughly double the available space for the characters. However the frame-rate dropped to 17 FPS and many times with picks of 12FPS.
With my trick (ported, again, from USA Racing) the frame rate raised again to 25 FPS, with rare picks of 17 FPS. And, also very important, giving 2-3 times (compared to the previous trick) more space for characters.
I know from Dario (the main coder) that this code was slightly changed on the final version. It removed the self-modifying part, because he observed that the code was almost always hitting (returning) to the same point. That's because the graphic assets on the final version had almost always the same size (the characters were split in small blocks and assembled at runtime to compose the complete shape) whereas my code was generic (it can handle graphics of any size). But, as I've said, it was just a slight change.

That's why Fightin' Spirit has so huge characters, with very reach animations, while still running at 25 FPS and in 64 colors (Using the Extra Half-Brite AKA EHB mode).

I should have saved some old source code versions (and the graphic assets as well ) of Perpetual Craze/Fightin' Spirit, somewhere on my hard drive.
Quote:
because in this case he would have been credited at least as additional coding.

It was because I've (and the graphic artist which was working with me on USA Racing) left the company before that the game was released.

However I was ready to make a lawsuit to get my part, since I contributed to the project.

It wasn't necessary at the very end, since nobody of my team got even a single cent from the sells. The game sold so poorly, because the Amiga market already dropped at the time. So, we all worked years... only for the glory.

That's also the reason why no one of us decided to continue on developing games: the delusion was so big that we took completely different roads.

Only Giacinto Platania (Perpetual Craze/Fightin' Spirit graphic artist) did some graphics for mobile phone games (someone recalls J2ME? ) but only as part-time / on-demand in his spare time (he also got a completely different job).
Quote:
With regards to USA racing, it was advertised on the game magazines of the time as work in progress, it was interesting with excellent graphics. My personal feeling is that it was far from complete and I never ever saw a demo of it running on Amiga.

No, the engine was at very good point.

There were some bugs on the AI for the cars and I had to better handle the collisions. But nothing which required a lot of time for being fixed.

Another thing which was still missing was the physics for the acceleration, deceleration and for the turns. I was seeking a physicist at the time to help, but I had also a plan B: copy what Trash Rally (it was our reference. Like Art of Fighting was for Perpetual Craze/Fightin' Spirit) did by reproducing the behavior of the cars rendered there.

However the biggest problem with USA Racing is that the game was IMMENSE, with an enormous graphic asset.
It had 640 32x32x32 colors tiles (400KB only for this!) for the map and the map was originally 4096x65535 pixels in size. It was so huge that in the last period it was decided to halve it to 2048x65536.
Then you've to take into account all cars to be draw and as well as all signals that are popping-up from time to time on the screen to inform of particular events (heavy right-turn, left-turn, zig-zap, etc. etc.).
Plus and to save memory I did NOT used masks for the tiles to be used for checking the collisions of the cars against some of them (e.g. rocks, trees, buildings, etc.). I've invented another technique to do the same, which had the advantage to be very useful for the car's AI. However it required time for the graphic artist to use / apply it on the big map.
All of this should have been made for each level: you can imagine how much big effort it required! I think that the only way to have ready in time was to have a graphic artist for each single level, working in parallel: no joke!

BTW I've originally planned to have much more. Technically, at least.
In fact, my idea was to load the tiles (and also cars) from the disk, during the game play. So, like SWIV.
The idea was to have the vertical screen split in 4 horizontal regions, from the bottom to the top. And reach region having its own set of tiles (and cars, eventually).
This would have produced a much richer and detailed graphic. However, and as you can see, the workload for the graphic artist was already so huge that this idea was abandoned.

At the end the biggest problem with both projects is that they were too much ambitious. But at the least the first one went to the market.
Quote:
One of the above magazines, The games machine, nowadays is archived online and it should be easy to find more info, if I have the time.

I've some scans saved on my hard driver. I can share, if you're interested. I've scanned them because Giacinto asked me some years ago for an interview.

@Gunnar

Quote:

Gunnar wrote:
Ciao Massi,

Come stai?

Quote:

Massi wrote:
@All

I am Italian and of the exact same age of Cesare.

For the sake of intellectual honesty, I do believe that Cesare participated to the development of the game Fighting Spirit, but very likely more in terms of ideas to the game engine rather then code. I doubt that the production code of the game contains code written by him because in this case he would have been credited at least as additional coding.

With regards to USA racing, it was advertised on the game magazines of the time as work in progress, it was interesting with excellent graphics. My personal feeling is that it was far from complete and I never ever saw a demo of it running on Amiga. One of the above magazines, The games machine, nowadays is archived online and it should be easy to find more info, if I have the time.


Many thanks for your feedback.
What you say is 100% the same what I think.

Fake war time stories can be funny if a grandpa tells them to his grandson.
"Listen kid when I was here with Buffalo Bill, it was the two of us against a million indians"
But fake stories are less funny here.

See above: why don't you stop talking of things where you have no clue at all?

You're a liar!
Quote:
Cesare nonsense talk like "To play PC game ports on Amiga you need little Endian modes"
this is all completely wrong, and claiming this shit does help no one here in the forum.

I never stated this: you completely invented this sentence and pretend to attribute to me even putting it under quotes.

You're a liar and dishonest!

BTW, Nuts also already on that part. All crazy, eh?

Last edited by cdimauro on 09-Oct-2022 at 06:17 AM.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Packed Versus Planar: FIGHT
Posted on 9-Oct-2022 8:02:58
#517 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3097
From: Germany

@Hypex

Quote:

Hypex wrote:
@cdimauro

Quote:
I've no statistics, but when I've checked WHDLoad games quite some of them required some Kickstart. I would be good to have some numbers.


When I installed WHDLoad it wouldn't work without any Kickstart. And that was before I installed any games. Must remember to check next time I boot my A4000.

Strange. Check again.
Quote:
Quote:
Correct. That's why you can talk about efficiency and then AMMX is clearly more efficient for some operations.

But it's when you talk about performances and saying that AMMX is faster than a PowerPC then you're lying.

The difference might sound subtle but it's essential.


It's all in the fine details and what was meant. It's easy enough to talk about performance in a misleading way. Of course how it performs outright is based on a number of factors including clock, memory speed and efficiency.

But, what we want to know is, the resulting speed. What is the quickest at doing an operation. Even so this is still apples and oranges. For one thing an ASIC CPU core isn't the same as an FPGA embedded CPU core. For another it's a different ISA. And different memory is used. There's talk of fast ram but an AmigaOne doesn't have fast ram in the Amiga chipset context of it. And a Vampire SA doesn't have fast ram either in the Amiga chipset context.

I thought Karlos provided a reasonable first test case for starters which was simple enough. But Gunnar wants to complicate it with a non-aligned vector soft sprite test. It might as well be an Amiga chip ram byte copy test vs. Vampire SA where the Apollo is faster because it doesn't have non-cached limitations of chip ram.

The discussion went further ahead, so nothing else to add here now.
Quote:
Quote:
No, x64 have also a better microarchitecture. I've shared several links to benchmarks on the code density thread and you can see that there isn't a huge clock difference between the tested systems, but x64 platforms as much faster on average compared to PowerPCs.


I've avoided that thread because I spend too much time reading here already. Well, there goes the RISC argument then. After AMD64 I thought x86 arch become a real mess. All these extensions put onto it. Extended opcodes. More lettering complicating simple register indexes and width specifying. And at end of the day x86-64 still wins.

I'm still not going to learn x64 ASM. It might be more complicated. But PPC64 ASM still looks more understandable!

Naah. x64 is quite easy and similar to 68k in many aspects. It's much more readable compared to PowerPC. IMO. It might be because I'm used to it since years now.
Quote:
Quote:
Sorry, but it's still wrong. Either you remove the & and replace it with a space, like I did it, or replace it with the HTML equivalent, like kolla suggested (which is much better).


Damn it. I know what it is. You cannot preview a post. If you preview is destroys HTML. I already tested it as working then made the mistake of previewing it but I think a pure HTML link is lost cause.

http://apollo-core.com/knowledge.php?b=4¬e=38817
Patents to Improve CPU Core?

OK, I see. It was Samurai Crow's thread. Which I've already mentioned here.
Quote:
Quote:
Maybe on some synthetic benchmark. Because the Sams are running at 1Ghz, so they are much faster than an Apollo core.

It's important to test an entire application / game and not just single routines.


That's why I had the idea for my Doom test. I was interested in testing a full game engine. Where I could modify it enough to give me results in a real world test.

Then it's better to try some of its OpenGL ports.
Quote:
Quote:
Indeed. In fact, Intel invented also the EPROM.


It just keeps getting better. At this point I'd like to admit that I think an Intel would have been a good CPU choice for the Hombre Amiga project. An Intel Itanium!

GLOM. No, please! Itanium was a failure, since the beginning.
Quote:
Quote:
Hum. V is better to be used for variable-length vectors. Maybe S = SIMD is a better prefix for those registers.


A for address. D for data. It logically follows to have V for vectors. At least to me.

Usually yes, but since several years "vector" is used for the variable-length extensions.
Quote:
Length should be coded as per the 68K dot width protocol.

Which length? The single lane/data length (8, 16, 32, 64-bit) ? Or the full register size (128, 256, 512, 1024)?

The 68k width protocol could be used for lane/data. But I've found another, more compact, solution for my NEx64T.
Quote:
I thought S was a grey as I recalled a MOVES but it's not listed in online searches. In any case both A and D stand for words but an S would stand for an acronym. (Or initialism).

Well, there are many other letters available.
Quote:
Technically, I see 68K has facing the same challenges as x86, since they are similar designs with a core CISC ISA. The 68K is less restrictive as it was designed with 16 registers with 32 bit width existing, divided into address and data as they may be, so not as pure GPR but later cores addressed this and gave more freedom. x86 was designed with a smaller register count and width which then had to be retrofitted on to expand the design. So 68K should be a better base to add vectors onto. However, both designs do have separate GPR and floats, in the register files, and where transistors are limited re-purposing floats does make sense.

Yes. For an embedded design it should be ok.

Anyway, usually either you use the FPU or the SIMD/Vector unit. And the latter has scalar equivalents for the parallel/packed instructions. So, reusing the FPU registers IMO is always fine.
Quote:
They already gave 80 bits width so enough for 64-bit vectors with 16-bits to spare or 5 words. But it would restrict it as floats and vectors would overlap.

Just extend them to 128 bit (at least)...
Quote:
However, in 68K ISA, it would also be expected to also perform memory to memory vector ops.

How? Mem-to-mem was only available for the general MOVE instruction. Plus there are a few arithmetic instructions with specific, fixed EA modes. So, there are no other mem-to-mem instructions on 68k.
Quote:
Quote:
floats could be 32-bit also.


That would be even more inferior to 80 bit and 64 bit floats.

Ah, ok. You were referring to the full FPU register size here.

Sure. 32-bit is not enough.
Quote:
Quote:
No, it this case the instruction is an AMMX one, which always operates on 64-bit data = quad word.


Apollo has 64 bit data registers then? Since it stored in a Dx. That looks wrong. Load/store? It's not a RISC. PPC needs to load then store. That looks more wrong for a 68K extension.

Indeed.
Quote:
Quote:
It would have been better to use a size suffix, like .q, but we know that Motorola also used default sizes for some instructions, so this is choice is in-line with what Motorola did.


Word default except for MOVEQ with long words yes. But it's still ambiguous. There are examples like MOVE16, so a LOAD8.B would fit in better. Aside from LOAD having no hints it's a vector op. Or a MOVE8.B since 68K standardised on MOVE.

Better to follow other ISAs and use something like PMOVE or PLOAD, etc.
Quote:
Quote:
Much better would have been to use a different syntax for the SIMD registers, like S2 in this case instead of D2, because D2 is causing confusion, like for you.


Yes it tells me it's loading into D2. I don't see it any other way. Redesign it before they start writing assembler parsers.

Already done, unfortunately...
Quote:
The store is even worse. A "storem.b" ? That tells it stores multiple bytes into memory but then only gives D2. What a waste, that looks pointless, like a "movem.b d2,(a1)+".

More or less. But to me the misleading part is the .b, since this instruction only supports bytes...
Quote:
Quote:
No, it merged the bytes from D2 with the bytes on (A1). If a byte is zero, then the corresponding byte on (A1) isn't changed. Otherwise it's replaced with the one from D2.


That's not a store, that's a merge!

Quote:
It's a merge / blend operation. Maybe a better name should have been used.


Yes, like merge. O blend. Mix.

Yup.
Quote:
Quote:
There some examples and a Programmer's guide on Discord. I've posted several links on the Code Density thread.


I'll take a link. At least I don't have to use Discord. Have an account but never used.

You don't need an account: you can get the manual by just clicking on the link (which us provided on the Apollo forum).
Quote:
Quote:
Sorry for that.


So was I. I knew he had major health conditions. But I was disappointed when all the last work he was doing wasn't published and I don't know what his family did with his Amigas or the data. I'm thinking I should at least release the work put I into it. Not like it has any big secrets. It uses a modified MultPlayer source to support and play a number of module formats and do scopes. I ported a few to AHI and they work fine on OS4. The way I approached it, unlike other AHI module players, at least on OS4 I've seen, is to use the module features of AHI to handle timing and mxing. It even checks and preselects the proper Paula mode if it exists so it uses hardware mixing.

If Mary or Monica in the Vampire core has an AHI driver which it should by now, it could be used to play classic modules in 16-bit resolution using hardware mixing. The way it should be.

AFAIR there's an AHI driver.
Quote:
Quote:
As I've said before, I would have preferred 8 or, even better, 16 audio channels. Leaving only a few sprites for the mouse pointer or some extra, small stuff.


That would have put more pressure on the blitter.

I know, but the lack of more audio channels is sensible.
Quote:
They would have needed to speed it up. Few sprites for a mouse pointer looks like such a VGA thing.

I agree. Sprites were too limited. Useful, since the Blitter had its own problems, but I preferred a more powerful Blitter (and system, in general).
Quote:
This doesn't seem to be well known or brought up in the subject. But did know the C16 actually did have a hardware sprite? Yes it had a hardware cursor!

ROFL
Quote:
That's not so funny. It was the way of the future. VGA chipsets embraced hardware cursors. C64 people thinking those 8 sprites were great. The C16 showed them where it was at! The way of the future. One sprite for your cursor.

But a much better system...

 Status: Offline
Profile     Report this post  
Gunnar 
Re: Packed Versus Planar: FIGHT
Posted on 9-Oct-2022 10:38:15
#518 ]
Regular Member
Joined: 25-Sep-2022
Posts: 152
From: Unknown

Quote:
Much better would have been to use a different syntax for the SIMD registers, like S2 in this case instead of D2, because D2 is causing confusion, like for you.


You misunderstand this.
This is not another register.
AMMX can also work on the Integer Register and this code example did use the Integer Register D2.



Quote:
Yes it tells me it's loading into D2. I don't see it any other way. Redesign it before they start writing assembler parsers.


You wrongly assume the SIMD unit would be limited to only new registers.
This is not the case.

In my opinion a very important feature of the 68K architecture is - that it always had less limits than some other architectures.

For example the 68K FPU - its not limited to FPU registers only.
The FPU could read /move from and to INTEGER registers.
Hammer made a point how Quake suffers on PowerPC FPU
and the reason for this performance problem
is the limitation of the PowerPC FPU not being able to write to INT registers.

Like the 68K FPU, the AMMX SIMD unit can also use Integer registers as source and destination.


Please read the 68080 documentation.
Than you make less wrong posts based on false assumptions.

Last edited by Gunnar on 09-Oct-2022 at 10:41 AM.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Packed Versus Planar: FIGHT
Posted on 9-Oct-2022 11:04:59
#519 ]
Elite Member
Joined: 24-Aug-2003
Posts: 3372
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Gunnar

How wide is D2 ? If the answer is 32 bits and you are using into process single 32-bit ARGB values at a time, it's not really SIMD, is it? Sure it's faster than doing each channel separately but the "data element" in the operation here is a 32-bit pixel, your code is doing them one at a time.

I appreciate this is splitting hairs.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Gunnar 
Re: Packed Versus Planar: FIGHT
Posted on 9-Oct-2022 11:09:08
#520 ]
Regular Member
Joined: 25-Sep-2022
Posts: 152
From: Unknown

Quote:

Quote:
Where are the games that you did in the 25 years after?
Where is anything?

Irrelevant. Another logical fallacy, but we know that you're used to them. You luck elementary logic.



Quote:

Quote:
Why did you not do anything at all, in the last 25 years?

Irrelevant again. You're the king of logical fallacies.


Lets talk about this:

I do love Amiga and many other people love Amiga too.
Many Amiga lovers can code, but some can not code.

Of the many coding one can do, some coding tasks are more difficult than others to do.
For example its often much easier to make a small demo, or write a small tool than making a full game. Making a game needs a real good coder.

All Amiga lovers that I know that still use Amiga and can code,
all enjoy coding and again and again continuously do this.
They write a demo here, a nice tool which end in Aminet there.
Maybe they write some improved datatype, maybe even a game.
But you need to be a good coder to make a game!


My friend, Cesare Di Mauro, you like to speak a lot about your coding inventions.
How you invented a new double buffering for Amiga ..
How you did something never seen on Amiga before.
How you made games.


The thing is that all the people that I know, that can code on Amiga - do code on Amiga again and again.

Are you really the one exception in the whole world?
Have great coding skills but never actually does code for Amiga at all?

Do you understand how strange and unbelievable this looks to all of us?


This is like someone claiming to be guitar rockstar, being a fantastic super player.
Do you have a guitar?
No! This is irrelevant!

Did you play guitar in the 30 years?
No! This is irrelevant!

This is all irrelevant. I real talented player never needs to play.
I'm a super talented guitar player.



This sounds just like a lot of bullshit to all of us.


Dear Friend, Cesare Di Mauro,

And when we talk about bullshit that were involved, then I always have to think about your involvement in the TINA project.

In the TINA project of you and your friends. Cesare Di Mauro, you and your friends did clearly name the ALTERA FPGA model the project would be using and you gave many technical details of TINA implements.

You and your friends boasted around with the claimed hardware features.
Just the same way like you brag with your invention on you unreleased game.

You guys bragged around that TINA has
- a 128Bit memory
- and 400 MHz CPU clock

But if you look at the ALTERA manual of this FPGA model, then we clearly see the memory bus can not go over 32bit, and the clockrate can not go over 200 MHz.

So all this bragged what was it?
Now tell me, were all the values claimed for the TINA project bullshit? Yes or No?

Last edited by Gunnar on 09-Oct-2022 at 11:16 AM.

 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 | 33 | 34 | 35 | 36 | 37 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