English Amiga Board


Go Back   English Amiga Board > Main > Retrogaming General Discussion

 
 
Thread Tools
Old 21 May 2020, 06:37   #281
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 37
Posts: 3,737
Quote:
Originally Posted by Gorf View Post
let's say some people are less than happy with the gaming experience of ocean games...
I'm one of them. They did have a few decent titles, but most of the stuff Ocean released was crap.
Hewitson is offline  
Old 21 May 2020, 09:14   #282
AmigaHope
Registered User
 
Join Date: Sep 2006
Location: New Sandusky
Posts: 680
Quote:
Originally Posted by Hewitson View Post
The idea of throwing around "tons of flat shaded polygons" on the Amiga is a very interesting one. This is something that, to my knowledge, hasn't been done before. Not in a game, anyway.

It would be fascinating to see the performance difference between a small amount of textured polygons versus a large amount of flat shaded polygons. It would also be good to see which one looked better.

Texture mapping looks better for less computation, once you have the hardware to do it. Normal mapping got added to texture mapping to enhance this effect, even -- all as a means to avoid calculating polygons. There's basically a threshold where a 3D model has enough geometry that you can cheat on representing more detail with a texture rather than polygons.

Of course it looks like crap if you get close enough, but that's why polygons are balanced with textures for whatever view distances are used (and why there are multiple LOD models used depending on distance, in order to minimize expensive polygons).

Although if you've seen the new Unreal Engine 5 demo, this may be changing again. UE5 has a new feature that culls polygon rendering down to the pixel level, letting extremely detailed models be used without having to render every triangle. It's sort of the best of both worlds. It took some serious oomph to make this possible though (rendering one triangle per pixel, plus the amount of RAM needed to store the complex models). Textures will now be more materials-based rather than as a stand-in for geometry.

But think about it, it's trivial to render a textured cube with textures that make it look like it's made out of bricks. It's way, way faster to render 6 squares/12 triangles and map a texture onto them than to try to render the tens of thousands of solid-shaded polygons needed to make a convincing brick surface on the sides.
AmigaHope is offline  
Old 21 May 2020, 10:07   #283
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 217
Quote:
Originally Posted by Gorf View Post
let's say some people are less than happy with the gaming experience of ocean games...
http://eab.abime.net/showpost.php?p=...&postcount=226

(the Amiga port of Dennis is even harder and some claim it was never a full port of all levels and they made it simply impossible to reach the higher ones..)
Oh, I see now. We didn't have a lot (don't really recall any now) of Ocean games on Atari, so while the brand rings a bell, that's about it...

Quote:
Originally Posted by Hewitson View Post
The idea of throwing around "tons of flat shaded polygons" on the Amiga is a very interesting one. This is something that, to my knowledge, hasn't been done before. Not in a game, anyway.

It would be fascinating to see the performance difference between a small amount of textured polygons versus a large amount of flat shaded polygons. It would also be good to see which one looked better.
Actually, that's what I'm trying to do with my game, though I want to keep main framerate locked at 30 fps for 320x240, so it won't really be a ton, as I gotta keep at least 50-60% of frame time unused for CPU spikes.

But, it looks like I can have around 1,000 tris (500 quads) for environment and about the same for enemies. So, about 2,000 tris.

If I was going for a slower-paced game, without frame-lock, where 15 fps is enough, Vampire should pull around 7,500 triangles per scene. Assuming no Z-Buffer is needed and polygons are largely pre-sorted, as sorting that many would just kill the framerate...

I reckon a 68060 should match Vampire's framerate pretty close, though I'm unclear what's the 32-bit bandwidth like on 68060. Probably would have to reduce background to 16-bit, or even just 256 colors (that would be nasty, though - not many shades for the space background - especially planets).
VladR is offline  
Old 21 May 2020, 14:16   #284
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 45
Posts: 1,441
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by VladR View Post
Oh, I see now. We didn't have a lot (don't really recall any now) of Ocean games on Atari, so while the brand rings a bell, that's about it...


Actually, that's what I'm trying to do with my game, though I want to keep main framerate locked at 30 fps for 320x240, so it won't really be a ton, as I gotta keep at least 50-60% of frame time unused for CPU spikes.

But, it looks like I can have around 1,000 tris (500 quads) for environment and about the same for enemies. So, about 2,000 tris.

If I was going for a slower-paced game, without frame-lock, where 15 fps is enough, Vampire should pull around 7,500 triangles per scene. Assuming no Z-Buffer is needed and polygons are largely pre-sorted, as sorting that many would just kill the framerate...

I reckon a 68060 should match Vampire's framerate pretty close, though I'm unclear what's the 32-bit bandwidth like on 68060. Probably would have to reduce background to 16-bit, or even just 256 colors (that would be nasty, though - not many shades for the space background - especially planets).
Remember that an Amiga can switch palette entries mid-screen. That helps 8 bpp get more than 256 colors.
Samurai_Crow is online now  
Old 21 May 2020, 20:18   #285
d4rk3lf
Registered User

d4rk3lf's Avatar
 
Join Date: Jul 2015
Location: Novi Sad, Serbia
Posts: 770
Quote:
Originally Posted by VladR View Post
256 colors (that would be nasty,
Imho, 256 colors (from the palette of 16.7 million colors) are more then enough for pretty much any image. Even 128 colors.
Especially in these small resolutions.

I had some troubles with gradients on the pictures, but mostly when used only 16 or 32 colors.
Attached Thumbnails
Click image for larger version

Name:	Screen_01.jpg
Views:	81
Size:	63.1 KB
ID:	67455   Click image for larger version

Name:	Screen_02.png
Views:	83
Size:	428.2 KB
ID:	67456  
d4rk3lf is offline  
Old 21 May 2020, 23:24   #286
khph_re
Registered User
 
Join Date: Feb 2008
Location: Northampton/UK
Posts: 263
Quote:
Originally Posted by VladR View Post

I reckon a 68060 should match Vampire's framerate pretty close, though I'm unclear what's the 32-bit bandwidth like on 68060. Probably would have to reduce background to 16-bit, or even just 256 colors (that would be nasty, though - not many shades for the space background - especially planets).
I've read that HAM mode in lowres 320 pixel mode can be treated as a virtual
106 pixel screen. Every three HAM pixels treated as one discreet pixel.

I'd expect that Hires would give you a 206 pixel screen, And super Hires a 412 one.

You'd then have a choice of 6bit 12k colours, or 8bit providing 16million.

I'm not a coder though, so I expect this could saturate the bus. Or some other problem that stops this from being used for anything but a still picture.
khph_re is online now  
Old 22 May 2020, 00:13   #287
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 769
Quote:
Originally Posted by khph_re View Post
I'm not a coder though, so I expect this could saturate the bus. Or some other problem that stops this from being used for anything but a still picture.

A lot of AGA demos use this trick - in conjunction with Chunky2Planar. It's pretty nice. If you're drawing to such a screen in realtime it's often easier to use groups of four pixels rather than three, with a fixed order of RGBGRGBG... or suchlike. The resolution is, of course, low - and while you can do the same thing in high-res it does get slower.


The low resolution would look pretty horrible with polygons, of course, but drawing the background using this trick, and then drawing base-palette polygons on top could be interesting. It would mean writing to two extra planes, however - so probably too slow for a high-framerate project.
robinsonb5 is online now  
Old 22 May 2020, 13:46   #288
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 713
Quote:
Originally Posted by khph_re View Post
You'd then have a choice of 6bit 12k colours, or 8bit providing 16million.
Small correction, in HAM6 (OCS/ECS) you get 4 bits per component which amounts to 4096 colors, and in HAM8 (AGA) you get 6 bits per component which amounts to 262144 colors.
britelite is offline  
Old 22 May 2020, 13:59   #289
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,964
It all depends on your perspective, I'd say.

As in, it's true that a single pixel HAM-8 modifier can't change more than 6 bits in one go. But on the other hand, there's nothing stopping you from using several such modifiers in a row (i.e. pixels). Which will allow you to get to any of the 16 million colours that AGA offers. Similarly, a HAM-8 base colour can be any 24 bit colour.

So it'll usually end up kind of in between 6 bits per component and 8 bits per component.
roondar is offline  
Old 22 May 2020, 16:36   #290
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 769
Quote:
Originally Posted by roondar View Post
It all depends on your perspective, I'd say.

As in, it's true that a single pixel HAM-8 modifier can't change more than 6 bits in one go. But on the other hand, there's nothing stopping you from using several such modifiers in a row (i.e. pixels). Which will allow you to get to any of the 16 million colours that AGA offers. Similarly, a HAM-8 base colour can be any 24 bit colour.
Ermmmm.... not quite. As you say, the base colours have eight bits of colour information per RGB channel so you have 24-bit freedom there.

However, HAM8 modifiers can only change the upper six bits, so from any given base colour you can only access 262,144 colours. However, because the lower two bits for each channel are inherited from the last base colour used, it's possible to access a different set of 262,144 colours from each base colour. In theory, then, it's possible to access any of the 16 million colours in HAM-8 mode, but not in a way that's generally useful.
robinsonb5 is online now  
Old 22 May 2020, 16:53   #291
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,964
Oh, that does change things a bit yeah...

Better option in that case is probably to switch base colours a bunch of times during the screen. But at any rate you won't get a full 24 bit set then.
roondar is offline  
Old 22 May 2020, 18:43   #292
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 713
Quote:
Originally Posted by roondar View Post
It all depends on your perspective, I'd say.
The context was HAM chunky modes, where you don't use the indexed colors
britelite is offline  
Old 22 May 2020, 19:00   #293
Locutus
Registered User

 
Join Date: Jul 2014
Location: Finland
Posts: 988
To get back to the Saturn, rather interesting video on it's VLIW co-processor:

[ Show youtube player ]

Sometimes it seems like a bummer it isn't remembered how cool the Saturn hardware is.
Locutus is online now  
Old 22 May 2020, 21:45   #294
AmigaHope
Registered User
 
Join Date: Sep 2006
Location: New Sandusky
Posts: 680
Quote:
Originally Posted by khph_re View Post
I've read that HAM mode in lowres 320 pixel mode can be treated as a virtual
106 pixel screen. Every three HAM pixels treated as one discreet pixel.

I'd expect that Hires would give you a 206 pixel screen, And super Hires a 412 one.

You'd then have a choice of 6bit 12k colours, or 8bit providing 16million.

I'm not a coder though, so I expect this could saturate the bus. Or some other problem that stops this from being used for anything but a still picture.

HAM doesn't work that way. You can use a closest-color algorithm for each pixel but it requires expensive computation. You can't turn a HAM pixel into one long pixel.

The 106 pixel mode you describe sounds a LOT like copper chunky though, which is achieved by setting a static bitmap and using the copper to bang the color registers instead (which will always yield the same number of horizontal pixels regardless of screenmode, because the copper has a fixed speed).

Quote:
Sometimes it seems like a bummer it isn't remembered how cool the Saturn hardware is.
Almost nothing used the Saturn's DSP because it was so damn hard to program for, and it wasn't really much faster than using the multiplication of the slave CPU instead.

Sonic R was a huge exception as it smartly split the workload between CPU and DSP to achieve a whole that neither independent entity could create on its own. It's a marvel of optimized code for a very finicky system.

Contrast the Playstation, which could achieve almost as much just using its easy-to-program GTE.

Sega's huge mistake was not having a better geometry engine to drive VDP-1. The DSP was slapped in as a hail mary.
AmigaHope is offline  
Old 22 May 2020, 22:18   #295
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 769
Quote:
Originally Posted by AmigaHope View Post
HAM doesn't work that way. You can use a closest-color algorithm for each pixel but it requires expensive computation. You can't turn a HAM pixel into one long pixel.

But you can group three pixels together, modifying first red, then green, then blue - which amounts to pretty much the same thing.


Quote:
The 106 pixel mode you describe sounds a LOT like copper chunky though, which is achieved by setting a static bitmap and using the copper to bang the color registers instead (which will always yield the same number of horizontal pixels regardless of screenmode, because the copper has a fixed speed).
Copperchunky is cool - I've used it myself (though again, no use at all for a polygon game) - but the method khph_re is talking about is just setting up a HAM screen, and setting the control planes to a static repeating pattern of modify-red, modify-green, modify-blue. (Often actually RGBG because repeating every 4 pixels can be easier to work with.)

Now you can ignore those two planes, and do chunky-to-planar on the remaining 4 (if HAM6) or 6 (if HAM8) planes, and treat it like a true-colour screen, albeit low-res.
(On ECS you can even use a chipset quirk to get truecolour-from-HAM6 for the same bandwidth you'd normally use for 4 planes.)

Loads of demos use this technique, but TRSI Rise is a particularly well-known example.
robinsonb5 is online now  
Old 24 May 2020, 07:23   #296
AmigaHope
Registered User
 
Join Date: Sep 2006
Location: New Sandusky
Posts: 680
Quote:
Originally Posted by robinsonb5 View Post
Now you can ignore those two planes, and do chunky-to-planar on the remaining 4 (if HAM6) or 6 (if HAM8) planes, and treat it like a true-colour screen, albeit low-res.
(On ECS you can even use a chipset quirk to get truecolour-from-HAM6 for the same bandwidth you'd normally use for 4 planes.)

Loads of demos use this technique, but TRSI Rise is a particularly well-known example.

Do you use sprites to mask the transition pixels or does it just create a horrible fringe effect on every pixel?
AmigaHope is offline  
Old 24 May 2020, 10:02   #297
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 769
Quote:
Originally Posted by AmigaHope View Post
Do you use sprites to mask the transition pixels or does it just create a horrible fringe effect on every pixel?
It just creates a horrible fringe effect on every pixel! Actually, no, it has a characteristic slightly-out-of-focus look, but it's not awful. See for yourself, if you wish - there's a little true-colour-on-HAM6 demo called "BumpMap" in the zone. (2 meg of RAM and '020 required, it seems)

And... bringing things vaguely back on topic... a couple of days ago I recorded the Minimig FPGA core running the block-man dance section at the end of Skarla Authentik - should give a useful performance data point.

This is, roughly speaking, 40Mhz '030 territory.

[ Show youtube player ]

I don't know how many of the transforms are pre-baked into the motion capture, or how much is done in realtime, but I still think a fast '030 should be able to run a fighting game featuring two such characters and keep the frame-rate high enough for it to be fun. How much the detail level could be increased on '040 or '060 while maintaining the framerate, I don't know.
robinsonb5 is online now  
Old 26 May 2020, 10:34   #298
Glen M
Registered User

 
Join Date: May 2017
Location: Belfast
Posts: 677
Its been a while since I responded here but I have been keeping up in the reading and it seems to be a resounding NO to the original question.

If it was possible to do, the likes of the block man dancer shown above I think would make a cool 3D fighter. I would hope that a fast 030 should be able to pull this off but from what you've all been saying maybe not.

Perhaps a pseudo 3D fighter would be possible like Ballz 3D on the SNES. It would just need to be good, Ballz sucks, er, balls
Glen M is offline  
Old 26 May 2020, 13:47   #299
Juz400
Registered User

 
Join Date: Mar 2017
Location: London
Posts: 105
Quote:
Originally Posted by d4rk3lf View Post
Between 14 (no joint boxes) to 22 (all joint boxes).
So,
22 boxes x 6 = 132 polygons (264 triangles)
Or,
14 x 6 = 84 polygons (168 triangles)

Attached image is (rough) sketch of the 22 boxes.

Edit:
And another image of rough sketch in pose, with 14 boxes.

D4rk3lf`s Idea in motion!


Quote:
Originally Posted by robinsonb5 View Post
It just creates a horrible fringe effect on every pixel! Actually, no, it has a characteristic slightly-out-of-focus look, but it's not awful. See for yourself, if you wish - there's a little true-colour-on-HAM6 demo called "BumpMap" in the zone. (2 meg of RAM and '020 required, it seems)

And... bringing things vaguely back on topic... a couple of days ago I recorded the Minimig FPGA core running the block-man dance section at the end of Skarla Authentik - should give a useful performance data point.

This is, roughly speaking, 40Mhz '030 territory.

[ Show youtube player ]

I don't know how many of the transforms are pre-baked into the motion capture, or how much is done in realtime, but I still think a fast '030 should be able to run a fighting game featuring two such characters and keep the frame-rate high enough for it to be fun. How much the detail level could be increased on '040 or '060 while maintaining the framerate, I don't know.

I think you are on to something here, the characters have all that is required for good starting point.
EDIT: have just run this demo on TF330`d CD32 (030@50Mhz) and runs pretty smooth all the way through.

Last edited by Juz400; 26 May 2020 at 14:09. Reason: Update
Juz400 is offline  
Old 27 May 2020, 14:56   #300
d4rk3lf
Registered User

d4rk3lf's Avatar
 
Join Date: Jul 2015
Location: Novi Sad, Serbia
Posts: 770
This is kind of interesting video I found on another thread.
I guess fighting games with characters like this would bi hilarious and interesting.

[ Show youtube player ]
d4rk3lf is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Found: Shadow Fighter (Was: Anime Fighter) LaundroMat Looking for a game name ? 6 14 June 2017 20:52
DKB Cobra/Viper 030 (Full 030) + FPU + Ram £100 ElectroBlaster MarketPlace 1 08 March 2013 12:52
DKB Viper 030 + 128mb simm for A500 030 + ram... ElectroBlaster Swapshop 0 18 August 2012 19:48
[Found: Virtua Cop] shootie game with a gun cosmicfrog Looking for a game name ? 11 05 October 2009 22:11
GVP G-force 030 board for A2000-problem switching between 030 and 68k Unregistered support.Hardware 5 19 August 2004 10:04

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 19:56.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.11223 seconds with 16 queries