English Amiga Board


Go Back   English Amiga Board > Main > Retrogaming General Discussion

 
 
Thread Tools
Old 04 February 2020, 13:29   #61
Old_Bob
BiO-sanitation Battalion

Old_Bob's Avatar
 
Join Date: Jun 2017
Location: Scotland
Posts: 64
Quote:
Originally Posted by Dunny View Post
He's right - how many of us played FA/18 Interceptor on stock A500s back in the day? And loved it, and were't really bothered about the framerate?

How many would like that same framerate today?
I'll see your FA/18 and raise you Crammond's F1GP. A *real* slideshow on an A500. And you're right, of course. It didn't stop me playing it.

B
Old_Bob is offline  
Old 04 February 2020, 23:27   #62
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 46
Posts: 1,633
Quote:
Originally Posted by Old_Bob View Post
I'll see your FA/18 and raise you Crammond's F1GP. A *real* slideshow on an A500. And you're right, of course. It didn't stop me playing it.

B
Driller on C64! I win
eXeler0 is offline  
Old 04 February 2020, 23:33   #63
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 46
Posts: 1,633
Quote:
Originally Posted by DamienD View Post
Although I'm a big fan of Virtua Racing and I'd probably like that one as well, its something "unholy" about playing that on my PC with a RTX 2070 SUPER card and admiring the flat shaded, untextured low poly assets.
eXeler0 is offline  
Old 04 February 2020, 23:42   #64
DamienD
Global Moderator

DamienD's Avatar
 
Join Date: Aug 2005
Location: London / Sydney
Age: 43
Posts: 16,927
Quote:
Originally Posted by eXeler0 View Post
Although I'm a big fan of Virtua Racing and I'd probably like that one as well, its something "unholy" about playing that on my PC with a RTX 2070 SUPER card and admiring the flat shaded, untextured low poly assets.
I hear you, I can always play the orginal via MAME for the ultimate experience though

...or if / when I can be bothered, download / setup a Sega MegaDrive emulator (I used to have this back in 1992 on my Sega MegaDrive and it was quite cool at the time).

Still, I think this new remake looks very cool so will probably purchase / have a bash
DamienD is offline  
Old 09 February 2020, 12:03   #65
d4rk3lf
Registered User

d4rk3lf's Avatar
 
Join Date: Jul 2015
Location: Novi Sad, Serbia
Posts: 664
Quote:
Originally Posted by Dunny View Post
He's right - how many of us played FA/18 Interceptor on stock A500s back in the day? And loved it, and were't really bothered about the framerate?

How many would like that same framerate today?
Well, even today, FA/18 interceror, for me personaly, runs at a fair speed. The only thing I'd like to be fixed, or patched, is that on faster comps, not to run faster (in terms of game time), but only faster in terms of fps. Frontier, for example, wotks fine in that matter.
I also think that Gunship 2000 runs pretty fine, at least, few missions I've played.
Not to mention crazy fps speed, for game like No Second Prize.

The point is: not all of us are spoiled by today standards.
d4rk3lf is offline  
Old 09 February 2020, 14:46   #66
Seiya
Registered User

Seiya's Avatar
 
Join Date: Nov 2014
Location: Italy
Posts: 1,012
It is a freeware remake. The Source Code is available not for free. Autor allowed that developer coud use it to make commercial game.
http://eicart.free.fr/RunOut/index.htm
Seiya is offline  
Old 09 February 2020, 23:59   #67
Dunny
Registered User

Dunny's Avatar
 
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 1,407
Quote:
Originally Posted by d4rk3lf View Post
Well, even today, FA/18 interceror, for me personaly, runs at a fair speed. The only thing I'd like to be fixed, or patched, is that on faster comps, not to run faster (in terms of game time), but only faster in terms of fps.
I used to play a fixed version on my A1200+030/50MHz and it ran at the correct speed, just silky smooth framerate. I can't remember the crack's name but it was definitely out there.
Dunny is offline  
Old 10 February 2020, 00:20   #68
DamienD
Global Moderator

DamienD's Avatar
 
Join Date: Aug 2005
Location: London / Sydney
Age: 43
Posts: 16,927
The only AGA fixed version in TOSEC is this:
FA-18 Interceptor (1988)(Electronic Arts)[f AGA - HD JOTD][h DrBong][HD][cp manual code].zip
DamienD is offline  
Old 10 February 2020, 08:10   #69
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 142
This is turning into a pretty significant rewrite

1. ClearScreen has to happen on CPU, though I wonder what would happen if we used Blitter - would it simply run at 7 MHz ?

2. Scanline fill - ditched my Blitter code and rewrote for CPU fill

3. First I ditched the RISC triangle rasterizer and used the quad rasterizer (wasn't used in the game, but I had some codebase running).

4. Then I rewrote the quad rasterizer with the floating-point math.

5. Then I found out there were some clipping scenarios that weren't taken care of, so I rewrote couple thousands of lines there.


Having finally rewritten all of the above, I've just found out that Amiga can't really handle composite of sprites and playfields that aren't bitplane, so the final composite of 2D background + HUD + 3D Scene Framebuffer has to be recreated every frame manually on CPU

Now this composite via ObjectProcessor wasn't completely free on Jaguar, it did have some performance impact in terms of total system bandwidth. But as long as you stayed within those bandwidth limits, it cost you Zero CPU time without any measurable framerate impact.

On Amiga, I will have to copy and fill every single pixel of those on-screen bitmaps every single frame...
VladR is offline  
Old 10 February 2020, 08:23   #70
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 142
While I don't doubt that in texturing will V4 be significantly faster than Jaguar (due to FPU and significantly larger caches), in flatshading it's currently very questionable (pending tests on real HW which I don't yet have).

The following functionality was ~free on Jag, but will have to happen with full CPU intervention here, for every single pixel:
1. FrameBuffer clear (on jag initiated as few register writes, then occurring fully in parallel with gpu/68000 code execution)
2. Polygon fill (~5-7% impact) - also occuring in parallel
3. 2D Background + GUI + FrameBuffer composite

The above will significantly eat into the 85-170 MIPS performance budget. Especially at 60 fps, this will add up quite fast, as we have roughly 1.4 MIPS per frame

Benchmarks will have to be run as to the size threshold of 2D background versus framebuffer clear - certainly if we have to copy it manually to framebuffer, no point in clearing that portion of framebuffer...
VladR is offline  
Old 10 February 2020, 10:15   #71
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 37
Posts: 3,594
Quote:
Originally Posted by VladR View Post
Because no poll in 2020, after everybody and their dog was exposed to constant 60+ fps on recent consoles, could remotely accurately describe actually how forgiving we all were [across all platforms] about the abysmal framerates 30 years ago.
Sadly most games STILL have abysmal framerates. Anyone who makes a 30 fps (or even less) game on a system as powerful as a PS4 or Xbox One can only be described as an absolutely appalling "coder".

Framerates were higher in 1982. The majority of C64 games run in one frame no worries.
Hewitson is offline  
Old 10 February 2020, 10:39   #72
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,395
Quote:
Originally Posted by Hewitson View Post
Sadly most games STILL have abysmal framerates. Anyone who makes a 30 fps (or even less) game on a system as powerful as a PS4 or Xbox One can only be described as an absolutely appalling "coder".

Framerates were higher in 1982. The majority of C64 games run in one frame no worries.
When I got an Amiga, there was often "something off" with the games I played, but I couldn't lay my hands on it. Everything felt so choppy and the games played badly, compared to the C64.

Only later off, I learned that it was mostly the frame rate that bothered me.

On the C64 (and on consoles I played before, like the Atari VCS) everything just ran full speed (except 3D games).
Steril707 is offline  
Old 10 February 2020, 11:08   #73
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,733
Quote:
Originally Posted by Steril707 View Post
On the C64 (and on consoles I played before, like the Atari VCS) everything just ran full speed (except 3D games).
Not to defend the practice of 25Hz updates (50Hz is obviously much more desirable and probably the only correct choice for 2D games released today), but I do think I understand why it happened.

On the Amiga* there is actually something to gain graphically from lowering frame rates: you can basically draw twice the objects by dropping to 25Hz. On the C64/VCS (and most 8/16 bit consoles), dropping the framerate in half will not actually really gain you any of that - it only allows more logic to run, not more objects to be shown.

Couple that with magazines and many customers calling 25Hz games "Arcade quality" and raving more about extra objects than smooth gameplay and you get this kind of thing. It's a shame too, because as we've been shown recently it's perfectly possible to make good/great games on the Amiga while running at 50Hz.

It's the same today: PS4 games that run at 30FPS often get rated higher for graphics than those that run at 60FPS. They also tend to sell quite well even with the lower frame rate. There seems to be no "sales bonus" for sticking to 60FPS, so developers often choose better graphics over higher frame rates.

*) just like on the PC, Atari ST, ZX-Spectrum, Amstrad and consoles as of the PS1.

Anyway, this is getting off-topic. So with that in mind...


----
@VladR
Regarding 3D flatshading on Vampire and the requirement for converting to planar graphics: doesn't the Vampire have "super AGA" and/or RTG graphics? I thought those modes did allow for chunky graphics?

If you're aiming at the Vampire anyway, those modes might be better suited than using Amiga native output. Assuming I'm not misremembering

Edit: I seem to have misread what you meant there, it seems you're talking about compositing only and not C2P.

In which case my question would be: perhaps I'm missing something, but I wonder why you would need to redraw the entire buffer for the compositing part? The 3D buffer needs to drawn for every frame regardless of any HUD/Sprites and surely the HUD elements/Sprites only need to change the pixels that they affect?

Last edited by roondar; 10 February 2020 at 11:20.
roondar is offline  
Old 10 February 2020, 11:20   #74
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 701
Quote:
Originally Posted by VladR View Post
The following functionality was ~free on Jag, but will have to happen with full CPU intervention here, for every single pixel:
1. FrameBuffer clear (on jag initiated as few register writes, then occurring fully in parallel with gpu/68000 code execution)
2. Polygon fill (~5-7% impact) - also occuring in parallel
3. 2D Background + GUI + FrameBuffer composite

I'm pretty sure there was talk a couple of years back about the Apollo core having multithreading capability. I've no idea how you would take advantage of it from user-code but it could potentially be a way to mitigate these issues.
robinsonb5 is online now  
Old 10 February 2020, 11:51   #75
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,062
Quote:
Originally Posted by VladR View Post
1. ClearScreen has to happen on CPU, though I wonder what would happen if we used Blitter - would it simply run at 7 MHz ?
You can clear about 3.3 MBps using the blitter (assuming no dma contention).

Quote:
Originally Posted by VladR View Post
Having finally rewritten all of the above, I've just found out that Amiga can't really handle composite of sprites and playfields that aren't bitplane, so the final composite of 2D background + HUD + 3D Scene Framebuffer has to be recreated every frame manually on CPU
I'm not sure what you mean by 'composite of sprites and playfields that aren't bitplane', but you could restore the 2D background using blitter/cpu/both, then draw vector gx using cpu, and use sprites for your HUD overlay.
hooverphonique is offline  
Old 10 February 2020, 13:20   #76
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 142
Quote:
Originally Posted by roondar View Post
@VladR
Regarding 3D flatshading on Vampire and the requirement for converting to planar graphics: doesn't the Vampire have "super AGA" and/or RTG graphics? I thought those modes did allow for chunky graphics?

If you're aiming at the Vampire anyway, those modes might be better suited than using Amiga native output. Assuming I'm not misremembering
Yeah, for now, it's Vampire-only, I am using CGX API. Though if enough interest manifests, I could later do a 060 version. After all, at this moment, I am developing against emulator, which means all my code is compiled against 040.


The AMMX and SAGA specific code will be merely an addition to the current codebase (I won't just delete all that code that is already running). Of course, I don't really anticipate the problem with the code - it's the final art assets. I highly doubt the Vampire-specific art assets will be playable on regular 060 - which is where most work would have to happen for 060 port.



Quote:
Originally Posted by roondar View Post
Edit: I seem to have misread what you meant there, it seems you're talking about compositing only and not C2P.

In which case my question would be: perhaps I'm missing something, but I wonder why you would need to redraw the entire buffer for the compositing part?
So, imagine a 2D Background plane - a pre-rendered skybox with buildings in the distance. That's the first part of composite that scrolls left/right/up/down with the camera.


Second part is 3D Framebuffer - where the flatshaded scene from current camera position is rendered.


Third part is HUD/GUI - that means the typical 320x64 bitmap with info on current speed, distance, time.
Also, there's a second HUD bitmap for the enemies that displays their stats - HP, Level, Armor, Damage, etc.
On Jaguar, if I had 5 on-screen enemies, I had 5 transparent such HUDs. I can absolutely forget about that here. That's too much CPU.

Now that I've tried the 24-bit shading, I don't want to loose it. So, that's basically 1 CPU op per pixel. That is going to add up.


Now, these sprite copies I should be able to come up with a code that is fully pipelined - e.g. both CPU pipes will be executing at full 170 MIPS speed without any pipeline bubbles. Still, this is something I was hoping to only pay the bandwidth price (not a CPU cycle per pixel).


Quote:
Originally Posted by roondar View Post

The 3D buffer needs to drawn for every frame regardless of any HUD/Sprites and surely the HUD elements/Sprites only need to change the pixels that they affect?
Well, it all has to be redrawn each frame because the HUD is transparent and you can see the polygons behind it, if camera gets into certain places.
But, since I am rewriting almost all this code anyway, I will redesign the HUD/GUI in a performance-conscious way.


Kinda like in the old 8-bit games, where the HUD will be an integral fixed part of the whole screen, zero transparency and will never have to be fully redrawn (merely need to draw the changes due to doublebuffering).


So, in a 320x240 scenario, if I keep -say- 320x40 for a HUD at the screen top (or bottom, unsure now), this will leave 320x200 for 3d scene+2d Background.


Since I will need to copy background every frame anyway, I can get away with not clearing the framebuffer (the 2D background will essentially clear it) and I will merely draw the 3D scene right into it.
VladR is offline  
Old 10 February 2020, 13:31   #77
coder76
Registered User

 
Join Date: Dec 2016
Location: Finland
Posts: 95
Well, I believe the problem is that with Vampire RTG graphics there is NO support for copper, sprites or e.g. dual playfield. It's just a dumb framebuffer. SAGA do have real hardware sprites, which are slightly better than AGA sprites in that they each have a separate 16 color palette and same 8 sprites that are 64 pix wide.

With sprites you could easily make a whole screen covering overlay at no extra cost. And with dual playfield you can split screen into one playfield that uses only blitter, and the other for CPU objects. But there's no real blitter in any of the Vampire cards, it's emulated by 68080 CPU, so you will get NO parallellism benefit here. With real OCS/ECS/AGA hardware and FAST memory, you can have blitter work in parallel with CPU, and even clearing chip ram memory at full speed, when CPU is also writing into chip ram.

I'm also not sure, if there already exist some 16-bit dual playfield /hybrid chunky/planar mode implemented in SAGA, which was at some point promised.
coder76 is offline  
Old 10 February 2020, 13:33   #78
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 142
Quote:
Originally Posted by robinsonb5 View Post
I'm pretty sure there was talk a couple of years back about the Apollo core having multithreading capability. I've no idea how you would take advantage of it from user-code but it could potentially be a way to mitigate these issues.
Multithreading on a single processor doesn't help performance at all. It would only take away the MIPS.


I already have a codebase that handles 5 processors in parallel execution on Jaguar:
1. Object Processor (the sprite engine displaying composite of all bitmaps)
2. RISC GPU (tight loop doing 3D transform + flatshading)
3. Blitter (clear screen, drawing scanlines of triangles)
4. RISC DSP (audio + other scene management)
5. 68000 (everything else - input, ai, gameplay, collision detection, ...)


The only Sync point is at the end of vblank. Other than that, all processors work independently of each other (each having a different priority on the bus).


At any moment, there are 3 different frames being worked on (last, current, next) - so it's a bi*ch to debug ...




Even having a tiny 7 MHz 68000 in parallel with 68080 would be very helpful to me, as it could be preparing next frame's polygon soup fully in parallel without halting main 080 CPU.


But, given how many features are currently outstanding for Vampire, this would require at the very least an additional team member to implement it (if they would even consider it a priority in the first place, considering the current features that need to be addressed).


I'm pretty sure people would revolt if , say, PCMCIA wouldn't be addressed, but rather something esoteric like this was to be implemented (assuming there even would be available gates on the board for something like this).
VladR is offline  
Old 10 February 2020, 13:46   #79
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 142
Quote:
Originally Posted by coder76 View Post
Well, I believe the problem is that with Vampire RTG graphics there is NO support for copper, sprites or e.g. dual playfield. It's just a dumb framebuffer. SAGA do have real hardware sprites, which are slightly better than AGA sprites in that they each have a separate 16 color palette and same 8 sprites that are 64 pix wide.

With sprites you could easily make a whole screen covering overlay at no extra cost. And with dual playfield you can split screen into one playfield that uses only blitter, and the other for CPU objects. But there's no real blitter in any of the Vampire cards, it's emulated by 68080 CPU, so you will get NO parallellism benefit here. With real OCS/ECS/AGA hardware and FAST memory, you can have blitter work in parallel with CPU, and even clearing chip ram memory at full speed, when CPU is also writing into chip ram.

I'm also not sure, if there already exist some 16-bit dual playfield /hybrid chunky/planar mode implemented in SAGA, which was at some point promised.
So, I really have zero exposure to Amiga, so don't know how this was handled in the past, but there was CGX API 20 yrs ago and plenty of GFX cards that supported it.


There's some calls in the API, like:
FillPixelArray - looks like could be used for clearing framebuffer
Read/Write/ScalePixelArray - looks to be useable for sprites
Un/LockBitmap


I would presume that these API calls must have been , in past, implemented in the HW (e.g. cards like Zorro, Picasso, etc.) right ?
Surely it wasn't CPU doing all that work ? Wouldn't the CGX driver merely collect the parameters and bang the proper HW registers on the card ?


So, perhaps, on Vampire, these calls have a parallel execution path to the 080 CPU?
VladR is offline  
Old 10 February 2020, 13:50   #80
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 142
Quote:
Originally Posted by hooverphonique View Post
You can clear about 3.3 MBps using the blitter (assuming no dma contention).
Thanks for the number.


3.3 MB @ 60 fps -> 55,000 Bytes per frame


That's less than 320x200@8bpp


So, it looks like it wouldn't be actually too useful.




Damn, I'm starting the appreciate the bloody buggy Jaguar HW more and more
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
Vampire Games sandruzzo Coders. General 220 13 September 2017 15:03
vampire V2 - what should i be using it for...? RobA1200 Amiga scene 238 17 July 2017 21:36
Vampire 1200 HanSolo support.Hardware 55 19 June 2017 10:15
Vampire x2 600 drusso66 support.Hardware 11 26 March 2017 10:18
Vampire II - Who is first? JackLeather support.Hardware 2 26 January 2016 13:56

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 23:19.


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