English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 05 July 2022, 22:51   #21
TCD
HOL/FTP busy bee
 
TCD's Avatar
 
Join Date: Sep 2006
Location: Germany
Age: 46
Posts: 31,612
Shh, you are ruining the fun of people thinking you can do AVP on a stock A1200

The Dread engine is very impressive, but it seems to be more capable of more because of how it is presented. I've played my fair bit of AVP on the Jaguar to know how much it is not just a Doom clone (let alone a Wolfenstein one).
TCD is offline  
Old 05 July 2022, 23:08   #22
jotd
This cat is no more
 
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,201
okay but if a 68k can do such things and we know that Doom runs well on 68040 even on native display, this game is probably doable, given some compromises.

But those compromises mean 1) get graphical assets 2) understand how they work so they can 3) be downscaled/color-reduced/whatever can be displayed quick enough.
jotd is offline  
Old 05 July 2022, 23:51   #23
lmimmfn
Registered User
 
Join Date: May 2018
Location: Ireland
Posts: 674
@Tsak
Dread is in its infancy, its geared towards OCS and 16 colours/limited sprite sizes. As far as I know there are plans to update it for AGA(don't quote me ? ).

Most of your points could be addressed with some engine updates except maybe the floor/ceiling textures.

It is the most optimal engine for the Amiga currently.
lmimmfn is offline  
Old 06 July 2022, 03:02   #24
Tsak
Pixelglass/Reimagine
 
Tsak's Avatar
 
Join Date: Jun 2012
Location: Athens
Posts: 1,035
Quote:
Originally Posted by lmimmfn View Post
@Tsak
Dread is in its infancy, its geared towards OCS and 16 colours/limited sprite sizes. As far as I know there are plans to update it for AGA(don't quote me ? ).

Most of your points could be addressed with some engine updates except maybe the floor/ceiling textures.

It is the most optimal engine for the Amiga currently.
I should know something as I'm one of the game's developers, right?
There are no current plans to update Dread for AGA (except perhaps as an afterthought and after the game and engine is finished and released). Plus there would need to be serious and targeted updates to address any of the points I raised. Well, perhaps someday
Tsak is offline  
Old 09 July 2022, 12:51   #25
lmimmfn
Registered User
 
Join Date: May 2018
Location: Ireland
Posts: 674
Quote:
Originally Posted by Tsak View Post
I should know something as I'm one of the game's developers, right?
There are no current plans to update Dread for AGA (except perhaps as an afterthought and after the game and engine is finished and released). Plus there would need to be serious and targeted updates to address any of the points I raised. Well, perhaps someday
haha, sorry, i'm an idiot, was on mobile and didn't realise it was you.

Maybe some day it could be updated
lmimmfn is offline  
Old 13 July 2022, 00:08   #26
VladR
Registered User
 
Join Date: Dec 2019
Location: North Dakota
Posts: 741
Quote:
Originally Posted by Tsak View Post
Well with OCS you have bigger problems than total colour count and that is the limited overal palette. I.e. the game will suffer tremendously with dark colors. But it should be still doable and looking fine (for a color reduced version). If you want near perfect results though then AGA only.
I don't necessarily care for exact port of the Jag's AVP, I played it for the first time just about 2 years ago, and it did not age particularly well, or maybe I just wasn't in the mood - either way - for me it's nowhere near the PC version which I consider one of the most atmospheric FPS ever, as the Marine campaign, especially first few levels, with constant spawning of aliens is something that in my opinion no other FPS on any subsequent platform managed to beat. The AI of Aliens is pure perfection (even if too hard).

I'm more interested in technical aspect of the 16-bit framebuffer, for my own selfish reasons - one being having spent entirely too much effort in creating my own Radiosity solver (for creating lightmaps).

I imported them into my engine on Vampire, and V4 is clearly fast enough to render vertical/horizontal strips of 16-bit textures.

Now I'm wondering where is the performance threshold for that kind of rendering on non-vampire configs. I'm pretty reasonably sure 040 has enough MIPS for that, but 040 is still beholden to the bitplanes, unless there is an accelerator with RTG board (at least that's my current understanding of the incredibly fragmented HW landscape on Amiga). Which means AGA, which means 256 colors.

And while the AVP's textures are just fine in 64 colors, the fine details of Radiosity lighting are impossible to convey with just 256 colors. Hell, Radiosity sucks at 65,536 colors - one really needs 16.7 Mil colors to avoid any artifacts (otherwise the rings are very obvious - as our eyes are fantastic for spotting the differences between the shades).

But, 16-bit would be useable.
Quote:
Originally Posted by Galahad/FLT View Post
Not only did I play it when it came out, I saw the source code to it at release as well

One of the guys at Imagitec had it, all written in pure 68000 ASM.

I'm not trying to shit on the Jaguar version by the way, I know its a great game, its not as good as the PC version which I completed with all three characters, but then again the PC needed to run AVP back in the day was quite a bit more expensive than a Jaguar, so its more a compliment to the Jag.

Pretty much the only game on the Jaguar that actually looked like it got close to using a decent mount of that 65,000 colour mode was a Rayman platformer, and that looks SUBTANTIALLY more colourful than AVP.

I think there are palette picking problems in AVP as from a distance, everything looks great, but move really close to walls especially when it comes to the Alien walls, and pixels quite often on rounded details look completely wrong, almost similar to HAM fringing on Amiga.
Oh, It wouldn't bother me if you did crap on the game, as it's not really a game I particularly cherish
You're spot on with Rayman. I can't say I played AVP enough on Jag to spot those texturing issues, though. I'll probably throw the cart in later today and check it out again on real jag (assuming the cart will power up).

Does it look like their mipmaps are not hand-drawn perhaps ? There's just 2 MB of RAM on jag, and double-buffered 320x200 takes 256 KB right off the start, so I can imagine they had to butcher their mipmaps somewhat...
VladR is offline  
Old 13 July 2022, 00:42   #27
VladR
Registered User
 
Join Date: Dec 2019
Location: North Dakota
Posts: 741
Quote:
Originally Posted by paraj View Post
While I don't think you'll be able to get 15fps in-game on a "real" 68K that way, more than 65K colors is possible with AGA using HAM8. This is typically done by converting each true color pixel into 4 color changes (RGBB) so you need to run in 1280x200 to get 320x200 "real" pixels. Since that takes a massive amount of chip cycles to pull off it was AFAIK only really used for still images. 160x100/160x128 true color wasn't uncommon in demos though.
While it may not be realistic to pull off real-time 3D each frame in that mode, the engine can certainly render a static image at loading-time, where it doesn't matter if it takes a second or two to render.
There's plenty game genres that are doable - like turn-based strategy/action games, which are doable in 3D, as long as your camera doesn't allow for free movement during your turn. Of course, adventure games are next prime candidate (with just one or two SW sprites on screen).

Quote:
Originally Posted by paraj View Post
To be honest, I don't really know. Never had a CD32 nor anything more fancy than an A1200, so not much experience there. I think CGX costs money? You should be able to code system friendly and have it work just as well for Amigas without graphics cards (at least if you're just doing normal 8-bit graphics). If you do that, it can always be optimized later on.
Regarding Akiko speed I found a benchmark in a forum post that suggest you're right about the cutoff:

You're right that you won't be limited by chipram speed outside the C2P routine. The problem is that 1280x256 HAM8 uses all available DMA slots while the display is active, so you're only left with 40% and you need to transfer 1280*256*6/32 (61440) longwords to update the display (the control plane bits can be left alone). Doing a bit of calculation, I think it'll take almost 84ms just to copy the data meaning you're limited to ~12fps (and this is without the game running)! You can probably improve on that by only transferring when the display is inactive, splitting it up over multiple frames and interleaving normal game logic with it, but it'll get really complicated. On the bright side C2P is essentially free on a 060 because chipram is so slow. There's even left over cycles available if you can find good use for them.
In other words 1280x256 HAM8 isn't really usable for a game on a 060, but luckily there are many different routes available if you're willing to make a few tradeoffs. Some of them were mentioned earlier, but obviously the "best" would be if you could restrict yourself to 256 colors. I only brought it up to highlight that you could get 16-bit color on AGA

Vertical doubling can be done with the copper (and you need to for OCS/ECS) but is much easier with AGA (using FMODE.BSCAN2). You don't save on display bandwidth, but halve the number of chipram writes. For 8-bit displays horizontal doubling is usually folded in with the C2P and just saves on having to calculate the game/effect at twice the resolution (no saving chip access wise, but if you're OK with half the vertical resolution it's probably OK vertically as well and you save overall computations). For HAM modes going from 1280 to 640 will of course halve the load.
Thanks, it all makes more sense now. I will go check out the FMODE.BSCAN2 (and all others). Looks like 8 bitplanes will have to be enough for real-time purposes then...
Did I get that right that just displaying a static 1280x256 HAM8 is impossible at 60 fps - e.g. the bandwidth of reading the bitplanes eats up so much time it takes multiple frames to just display whole thing ? Doesn't it flicker like crazy then ? Or is it just tearing ?
VladR is offline  
Old 13 July 2022, 10:38   #28
chb
Registered User
 
Join Date: Dec 2014
Location: germany
Posts: 439
Quote:
Originally Posted by VladR View Post
Did I get that right that just displaying a static 1280x256 HAM8 is impossible at 60 fps - e.g. the bandwidth of reading the bitplanes eats up so much time it takes multiple frames to just display whole thing ? Doesn't it flicker like crazy then ? Or is it just tearing ?
Displaying a static image at 1280x256 at 50 fps is perfectly possible, the graphics chip (Lisa) has much more bandwidth to the chipram than the CPU. But as paraj wrote, at that resolution there's not much bandwidth left for the CPU to write to chipram due to display DMA taking almost all of it. And even when no display is active, writing a complete 1280x256x8 image to chip takes several frames.
chb is offline  
Old 14 July 2022, 17:06   #29
VladR
Registered User
 
Join Date: Dec 2019
Location: North Dakota
Posts: 741
Quote:
Originally Posted by chb View Post
Displaying a static image at 1280x256 at 50 fps is perfectly possible, the graphics chip (Lisa) has much more bandwidth to the chipram than the CPU. But as paraj wrote, at that resolution there's not much bandwidth left for the CPU to write to chipram due to display DMA taking almost all of it. And even when no display is active, writing a complete 1280x256x8 image to chip takes several frames.
Oh, ok. So, then it's still perfectly possible to use for screen-based games, like adventures or platformers (with HW sprites), where it's OK if it takes a second to render the screen when going from one screen to another.

Or a grid-based dungeon, where all sprites are SW sprites anyway. Though, that might get annoying if it takes half a second for each step to rerender the screen.

But a 3D turn-based strategy is perfectly doable - upon change of turn, the engine just renders the 3D scene which is then a static image for the remainder of the turn.
And the GUI with all turn commands could be in some lower resolution, at the bottom of the screen, say 256 colors is certainly more than enough for that.


This mode is certainly very useable for in-game GUI, like:
- Menus
- Maps
- Loading Screens
- Inventory (RPG games)

A galactic map, for a game like Star Raiders, could look amazing in this res.
And probably no sane person with 060 would have less than 16 MB of RAM, so you could even keep few static versions pre-rendered and just quickly update the enemy overlay on CPU before displaying it (hence it wouldn't take half second to update).


No need for RTG gfx card, indeed. And this technology/option was available in 1992 ? Huh...
VladR is offline  
Old 14 July 2022, 17:20   #30
VladR
Registered User
 
Join Date: Dec 2019
Location: North Dakota
Posts: 741
Quote:
Originally Posted by TCD View Post
I've played my fair bit of AVP on the Jaguar to know how much it is not just a Doom clone (let alone a Wolfenstein one).
I get it, that the game has a different, much slower pace than Wolf. That's fine.

Could you please elaborate more on this ? This is AVP thread, after all. From technological standpoint, the engine is very simplistic compared to Doom.

The level design is grid-based and other than textured floor/ceiling and transparent walls in 65,536 colors, I don't see it much different than Wolf.

I did, just now, notice that when you play as Predator, one of the vision modes halves the resolution to half to 160x200.
VladR is offline  
Old 14 July 2022, 17:34   #31
TCD
HOL/FTP busy bee
 
TCD's Avatar
 
Join Date: Sep 2006
Location: Germany
Age: 46
Posts: 31,612
The transparent HUD, the different floors of the space station (which might be trivial, but as an alien you can use the ducts, so maybe not) and the different vision modes of the Predator. I'm sure the basic 3D engine is pretty simple, but I'm not convinced you can easily recreate all features of the game with a Wolf clone engine.
TCD is offline  
Old 14 July 2022, 20:18   #32
VladR
Registered User
 
Join Date: Dec 2019
Location: North Dakota
Posts: 741
Quote:
Originally Posted by TCD View Post
The transparent HUD, the different floors of the space station (which might be trivial, but as an alien you can use the ducts, so maybe not) and the different vision modes of the Predator. I'm sure the basic 3D engine is pretty simple, but I'm not convinced you can easily recreate all features of the game with a Wolf clone engine.
Yeah, I doubt you could have the Alien's duct system in a Wolf clone without some serious refactoring.
VladR 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
68000 code optimisations pmc Coders. Asm / Hardware 248 17 September 2023 13:20
68020 to 68000 code convertion using Ira and PhxAss gulliver Coders. Asm / Hardware 18 12 April 2014 01:09
68000 boot code billt Coders. General 15 05 May 2012 20:13
Alien vs Predator, MS-DOS s2325 request.Old Rare Games 11 20 June 2009 12:51
WANTED: Alien vs Predator For Atrai Jaguar Andrew MarketPlace 2 01 July 2003 19:43

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 21:11.

Top

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