English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 03 October 2019, 11:49   #181
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,595
@KK/Altair

Since in a game like Wolf3d walls are fixed as real size to positions, you can prerotate one blocks, and in realtime, you have only to put into right position. Example: I've used wall as 64*64 unit, so I prerotated them into a table, then in realtime, I pick-up the right angle based upon Camera rotation. To have the right position on screen I did this: Just rotated walls' pos and voilĂ ! I think I can even precalculate it. About Projection, I maybe we can use 1/z to do One Divs and 2 muls, instead 2 divs.

I'm still try to figure out if is it possible to use interleaved bitplanes, since they are some sort of y-chunky, and if we can precalculate texture by 16 pixel to make them blitter friendly

Last edited by sandruzzo; 03 October 2019 at 12:12.
sandruzzo is offline  
Old 03 October 2019, 12:26   #182
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 606
Quote:
Originally Posted by sandruzzo View Post
Since in a game like Wolf3d walls are fixed as real size to positions, you can prerotate one blocks, and in realtime, you have only to put into right position. Example: I've used wall as 64*64 unit, so I prerotated them into a table, then in realtime, I pick-up the right angle based upon Camera rotation. To have the right position on screen I did this: Just rotated walls' pos and voilĂ ! I think I can even precalculate it. About Projection, I maybe we can use 1/z to do One Divs and 2 muls, instead 2 divs.
Just to be clear, are you talking about rebuilding the visible portion of the map with prerotated blocks? Which would then be used for rendering the walls on screen?
britelite is offline  
Old 03 October 2019, 12:43   #183
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,595
Quote:
Originally Posted by britelite View Post
Just to be clear, are you talking about rebuilding the visible portion of the map with prerotated blocks? Which would then be used for rendering the walls on screen?
Yes, since that, would be easy with poligons to have walls rotated and not only orthogonals!
sandruzzo is offline  
Old 03 October 2019, 12:47   #184
d4rk3lf
Registered User

d4rk3lf's Avatar
 
Join Date: Jul 2015
Location: Novi Sad, Serbia
Posts: 513
Quote:
Originally Posted by malko View Post
Tss, tss, tss
It's like saying you don't need to finish <put anything here> because others already have finished something similar
It's like saying you don't need a hot woman, because others have it. :P

@Britelite
Your Wolf3D engine is also amazing.
Please, keep it up.
d4rk3lf is offline  
Old 06 October 2019, 00:17   #185
x-vision
Registered User

 
Join Date: Oct 2019
Location: Spain
Posts: 2
Quote:
Originally Posted by KK/Altair View Post
Thank you guys for all the kind words!! (and for the other kind of "kind" too - just ignore that)

If you have any kind of questions about this little thing, just fire away here. I will definitely check this tread, because of just how awesome your reaction was!

So, to address the more common questions...

1. The game DOES run on a stock A500 exactly how it does in WinUAE - if you watch my presentation closely, you'll see that I restarted the demo just because it was running too fast (it does in WinUAE in non-cycle-exact modes). The point of the presentation was just to give a few tricks away and not to show the game, so there was no actual hardware used. But if you ask anyone attending Decrunch 2049 party, they would confirm that it runs indeed because I gave a stealthy show there.

2. Don't compliment me on the art. All the graphics are converted from FreeDoom, which thankfully is covered by BSD license and I can focus on coding. Level design is done by me, because it has to adhere to the engine limitations.

3. This will be a "doom clone", so don't expect Doom port from this project. In no close point in the future the engine will be able to handle complexity of Doom maps. So, instead it's much better to design maps that allow acceptable gameplay (10+ FPS) on a A500 1MB and make a fresh thing. On the other hand, this also allows having features NOT present in Doom - like sliding doors, which are already implemented. But multi-floor buildings would also be something I'd love to have down the road.

4. The performance so far is roughly:
- 10-14 FPS - A500+1MB
- 24-25 FPS - stock A1200
- 30 FPS - A600 with Furia
But the A500 performance is the king here. Every possible optimization that could improve the framerate on A500 is a clear win for me, even if it would cripple the remaining configs somehow. Stronger configs have good FPS games already, and I really want to fill the A500 gap.

5. The demo features so far:
- 3 different ceiling heights + sky,
- 2 light levels (this is really a trick - I change textures and floor/ceil colors),
- angled walls,
- flat floor and fixed camera height,
- 4 weapons (pistol, shotgun, chaingun, rocket launcher),
- 3 types of monsters (shotgunner, chaingunner, flying monster),
- large map with keycards and (sliding) doors,

6. The fixed camera height is a limitation allowing several optimization tricks. In worst case scenario, the camera will move vertically in fixed steps - after all, moving camera is the same as moving rest of the map up and down. In best case - I'll figure a clever way to get around this. Right now, having limited number of possible drawing heights allowed me to bring performance to acceptable levels and focus on making a playable demo from what I got. We don't want just an another tech demo with no gameplay, right? But this is clearly a point I'll have to go back to.

7. Last, but definitely not least - I have not released binary so far. I have already spent a better half of the year on that and pretty burned my motivation by this point. But there is still SO much work ahead, so I'm still thinking about how to get the best motivational boost from what I have so far. Right now I'm considering releasing this (and any regular updates I make from this point) via Patreon and/or itch.io, but got kind of stuck in the decision because of how it would limit the availability, on the other hand. I'm already at the point where I can barely look at this code, so something should be done about that. In any case, community modding will be a big point in the process, so everybody interested could have as much fun as possible even with unfinished product, while, at the same time, helping me.

In any case, feel free to ask and comment here as much as you like!


Thanks,
KK/Altair
First of all congrats for your wonderful work! it looks awesome, and also for you attitude disclosing all the techniques you use and being open to discussion.

The only "flaw" I see in your engine is that colors don't certainly look very good (yet), so I would like to ask if you considered HAM mode.

I know it may sound crazy, but according to this dev:

[ Show youtube player ]

[ Show youtube player ]

His engine didn't get slower because of it being in HAM8 , but because it's in hi-res (you can check in the comments of the second video)

And this one (althought probably in lower resolution) seems to work quick on a stock 1200
[ Show youtube player ].

And different question: if you are managing polygons, would the engine be capable of showing something similar to quake? (imagine it aplying the same kind of restrictions you are using right now for sizes, visualization, light, etc...)
x-vision is offline  
Old 06 October 2019, 21:47   #186
d4rk3lf
Registered User

d4rk3lf's Avatar
 
Join Date: Jul 2015
Location: Novi Sad, Serbia
Posts: 513
Quote:
Originally Posted by x-vision View Post
The only "flaw" I see in your engine is that colors don't certainly look very good (yet), so I would like to ask if you considered HAM mode.
Personally, I like better the look he already have, then the sample you posted. Sometimes less (colors) is more.
It would be cool that kind of style, for some fantasy rpg game, but for the doom/ marine, military style, I rather go with that gray, metal look... looks more serious.

He is using that graphics, just as a temporary texture assets, thou.
I really hope the final textures will look similar as this one he already using, because I really like the look.
d4rk3lf is offline  
Old 07 October 2019, 01:01   #187
Dunny
Registered User

Dunny's Avatar
 
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 1,322
Quote:
Originally Posted by x-vision View Post
The only "flaw" I see in your engine is that colors don't certainly look very good (yet), so I would like to ask if you considered HAM mode.
HAM mode, seriously? I mean, do you not see the awful colour-fringing in those videos?
Dunny is offline  
Old 07 October 2019, 03:26   #188
lmimmfn
Registered User

 
Join Date: May 2018
Location: Mullingar
Posts: 52
Quote:
Originally Posted by Dunny View Post
HAM mode, seriously? I mean, do you not see the awful colour-fringing in those videos?
I thought that was quite intriguing tbh, not saying it would work for this doom engine but intriguing nonetheless and performance was pretty decent
lmimmfn is offline  
Old 08 October 2019, 21:40   #189
KK/Altair
Registered User

 
Join Date: Sep 2019
Location: Gdansk / Poland
Posts: 30
Quote:
First of all congrats for your wonderful work! it looks awesome, and also for you attitude disclosing all the techniques you use and being open to discussion.
Thanks! I just see no point in hiding that information, so you all can discuss as much as you'd like. It will only be for the better of the engine.



Quote:
The only "flaw" I see in your engine is that colors don't certainly look very good (yet), so I would like to ask if you considered HAM mode.
Considered for about 5 seconds and scratched that idea almost immediately. Anything above 4 bitplanes starts cutting into CPU time too much, and I need that time to make framerate at least somewhat acceptable. Right now I keep balancing somewhere in the 10-12 FPS region, which I consider the acceptable minimum.


But note that I didn't make the assets nor didn't put extreme efforts into conversion, so there certainly are people around that would do much better job at this (and I'd love to let them, as soon as the game starts being moddable).


Quote:
His engine didn't get slower because of it being in HAM8
I don't know anything about AGA timing, 020 cache performance nor about his engine architecture. But OCS/68000 is completely different case and here anything above 4 bitplanes start heavily cutting into CPU time. And my engine is supposed to be playable on a stock A500 (+512k slow, that is). Also anything else than 4bpp would require completely diffrent C2P setup, so as much as I'd like having 5bpp, that's for another time.



Quote:
And different question: if you are managing polygons, would the engine be capable of showing something similar to quake? (imagine it aplying the same kind of restrictions you are using right now for sizes, visualization, light, etc...)
Quake requires completely different textrure mapping. In Doom, when drawing by columns, you can get away with much cheaper routine, because X texture coordinate stays constant. Also Doom restrictions also make zero-overdraw rendering simpler, because for any given screen column at any given time, there is only one continuous gap remaining.


But feature-wise, angled ceilings and floors are not out of question (but still flat-shaded).


Quote:
It would be cool that kind of style, for some fantasy rpg game, but for the doom/ marine, military style, I rather go with that gray, metal look... looks more serious.
I've just taken some textures from FreeDoom (which tries to make similar replacements for all Doom assets) and tried to come up with an acceptable palette for it. But I can completely imagine something in a different style.


Quote:
He is using that graphics, just as a temporary texture assets, thou.
I really hope the final textures will look similar as this one he already using, because I really like the look.
The fact is, that FreeDoom is covered by BSD license, so I can freely use all the assets as they are. I'm not attached to them, so if anyone steps up willing to contribute to the project, I'd be more than willing to accept the help, but otherwise they all may go all the way to the final build. I just want to focus on the engine and gameplay.
KK/Altair is offline  
Old 09 October 2019, 14:31   #190
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 623
Quote:
Originally Posted by KK/Altair View Post
Considered for about 5 seconds and scratched that idea almost immediately. Anything above 4 bitplanes starts cutting into CPU time too much
If you did want to pursue this at some point in the future, there's a quirk in the non-AGA Amiga chipset where if you set the number of bitplanes to 7, DMA fetches only four planes but Denise behaves as though six are active. This means it's possible to have a fixed repeating pattern loaded into BPL[5|6]DAT registers (setting the HAM control bits to, for example, R G B G R G B G) but with the same performance as a four bitplane display. It doesn't work on AGA, but on AGA cranking up the fetchmode solves the bandwidth problem anyway.
robinsonb5 is offline  
Old 09 October 2019, 16:47   #191
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 196
Quote:
Originally Posted by robinsonb5 View Post
If you did want to pursue this at some point in the future, there's a quirk in the non-AGA Amiga chipset where if you set the number of bitplanes to 7, DMA fetches only four planes but Denise behaves as though six are active. This means it's possible to have a fixed repeating pattern loaded into BPL[5|6]DAT registers (setting the HAM control bits to, for example, R G B G R G B G) but with the same performance as a four bitplane display. It doesn't work on AGA, but on AGA cranking up the fetchmode solves the bandwidth problem anyway.
Yep, I did some experiments with such a setup a while ago. The easiest way IMHO is to use a palette color for every even pixel and modify the green channel for every odd one. That means setting BPL5DAT and BPL6DAT to 0x5555. Every 2x2 pixel block is completely independent from every other, so the format works exactly like before (just change screenmode, those two BPLDATs and of course the texture data and palette).

I have attached some test images. The method I've used is very quick and dirty: Convert the image to 16 colors (I've used just Gimp without any tweaking, no dithering), use that for the even pixel (R_16, G_16, B_16), compute the error for the green channel and change the odd pixel's green value G' so that the average of those two pixel's greens equals the original one G_original:

Code:
G' = 2*G_original - G_16  (check for zero and 0xF)
Then just double every line.

There's a lot of possible improvements to this very simple algorithm, but I thought I just share those results. Some examples show very noticeable color artifacts (green/purple mostly) that could be reduced with some smarter algorithm, e.g. introducing a hue threshold. Also choosing the 16 color base palette with the green modification in mind could improve image quality.

Images are as following: original (160x90 without doubled pixels in x and y) and ham version (doubled in y, dithered as described in x). Both with 4 bit per color channel. Two images from the freedoom page, the ubiquitous Lenna image and an image from Big Buck Bunny.
Attached Thumbnails
Click image for larger version

Name:	doom2_orig.png
Views:	232
Size:	10.1 KB
ID:	64691   Click image for larger version

Name:	doom2_ham.png
Views:	219
Size:	15.6 KB
ID:	64692   Click image for larger version

Name:	doom4_orig.png
Views:	201
Size:	13.7 KB
ID:	64693   Click image for larger version

Name:	doom4_ham.png
Views:	215
Size:	23.0 KB
ID:	64694   Click image for larger version

Name:	lenna_orig.png
Views:	190
Size:	12.3 KB
ID:	64695  

Click image for larger version

Name:	lenna_ham.png
Views:	185
Size:	20.2 KB
ID:	64696   Click image for larger version

Name:	bbb4_orig.png
Views:	191
Size:	9.2 KB
ID:	64697   Click image for larger version

Name:	bbb4_ham.png
Views:	203
Size:	14.8 KB
ID:	64698  

Last edited by chb; 09 October 2019 at 16:58. Reason: mixed up even and odd - first pixel has index 0. :)
chb is offline  
Old 25 October 2019, 11:01   #192
KK/Altair
Registered User

 
Join Date: Sep 2019
Location: Gdansk / Poland
Posts: 30
Quote:
There's a lot of possible improvements to this very simple algorithm, but I thought I just share those results. Some examples show very noticeable color artifacts (green/purple mostly) that could be reduced with some smarter algorithm, e.g. introducing a hue threshold. Also choosing the 16 color base palette with the green modification in mind could improve image quality.
Thanks for sharing the results! I was thinking about this exact method, too, but haven't got around to checking whether it's actually worth it. And now your results really convinced me.

I don't really mind the dithering artifacts, because in your images they are comparable or better to what I'm having now with just dithering the palette. The only real problem with this method is that AFAIK it won't on AGA chipsets, which would require fall back to current method... making OCS surpass AGA in image quality for the first time ever.
KK/Altair is offline  
Old 25 October 2019, 11:07   #193
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 471
Quote:
Originally Posted by KK/Altair View Post
Thanks for sharing the results! I was thinking about this exact method, too, but haven't got around to checking whether it's actually worth it. And now your results really convinced me.

I don't really mind the dithering artifacts, because in your images they are comparable or better to what I'm having now with just dithering the palette. The only real problem with this method is that AFAIK it won't on AGA chipsets, which would require fall back to current method... making OCS surpass AGA in image quality for the first time ever.
It should work on AGA... you just need to enable regular HAM mode with the "mask" actually set as full bitplanes for planes 5 and 6
DanScott is online now  
Old 25 October 2019, 11:13   #194
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,164
Quote:
Originally Posted by DanScott View Post
It should work on AGA... you just need to enable regular HAM mode with the "mask" actually set as full bitplanes for planes 5 and 6
This is how I fixed Sushi Boyz bump mapping part
ross is offline  
Old 25 October 2019, 11:17   #195
malko
Ex nihilo nihil

malko's Avatar
 
Join Date: Oct 2017
Location: CH
Posts: 2,269
@chb: the result is really cool ! Nice colour selection.
malko is offline  
Old 26 October 2019, 07:46   #196
b0lt-thrower
Registered User
 
Join Date: Jun 2010
Location: US
Posts: 87
KK can I ask a dumb question? And I promise this is going to be legitimately dumb so I apologize in advance: I swear I'm not trying to be a pest!

Okay, in your screenshots we can see you have variable height ceilings...but you have said the map will have fixed height floors. Could you not (depending on the room)...erm..."flip" the map so that your floor becomes the ceiling? And then have a variable height floor in some cases?
b0lt-thrower is offline  
Old 05 November 2019, 11:10   #197
KK/Altair
Registered User

 
Join Date: Sep 2019
Location: Gdansk / Poland
Posts: 30
Quote:
It should work on AGA... you just need to enable regular HAM mode with the "mask" actually set as full bitplanes for planes 5 and 6
A perfectly reasonable solution I'm ashamed of not thinking of. Eats some chip memory, but I should manage.

Quote:
Okay, in your screenshots we can see you have variable height ceilings...but you have said the map will have fixed height floors. Could you not (depending on the room)...erm..."flip" the map so that your floor becomes the ceiling? And then have a variable height floor in some cases?
Nothing dumb here. This is perfectly reasonable and I was already considering making pits, rivers and bridges this way.

The problem is, though, that I have a separate line drawing function for each line mode (where line is a 2D line on the top-down map view). So, for example, one of the functions would be responsible for drawing:
- Z = top ... -128 --- sky
- Z = -128 ... -64 --- texture
- Z = -64 ... 0 --- gap (skips this part and sets Ymin/Ymax to clip further lines)
- Z = 0 ... bottom --- floor color

For all possible combinations, including whether the line is first one visible (no clipping needed) and if perspective correction is on/off (I control that dynamically per-line) I have currently 50-something of such functions. Of course they are automatically generated, but the generator is already complex and adding floors would blow that to the sky...

So, instead I decided that I should focus on the gameplay and return to the topic later. And in the meantime I've got idea how to handle it better and completely, so instead of just adding floors, this part is waiting for a total rewrite. But with full Z support this time.
KK/Altair is offline  
Old 05 November 2019, 11:12   #198
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,595
Just a Thought: but, by setting interleaved bitplanes, and using lines drawing with blitter, should that be fast enough for gaming?
sandruzzo is offline  
Old 05 November 2019, 22:53   #199
KK/Altair
Registered User

 
Join Date: Sep 2019
Location: Gdansk / Poland
Posts: 30
Quote:
Originally Posted by sandruzzo View Post
Just a Thought: but, by setting interleaved bitplanes, and using lines drawing with blitter, should that be fast enough for gaming?
I don't quite understand - what would you exactly draw with the Blitter?
KK/Altair is offline  
Old 05 November 2019, 23:50   #200
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,595
Quote:
Originally Posted by KK/Altair View Post
I don't quite understand - what would you exactly draw with the Blitter?
I did a test with blitter, and it's possible to do with it cp2 via line drawing. By setting interleaved bitplane you can do it. And since you can drive blitter with copper, the only thing that cpu have to do is feeding blitter register with 4, 16 colors chunky pixels!
sandruzzo 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
Amiga DRAM chip tester for HYB-514256B with Arduino UNO - Amiga 500/500+ andy2018 support.Hardware 0 31 October 2018 22:27
Amiga 500 Rev.6A VS Amiga 500 Plus with 2MB chip and ACA 500 turrican9 support.Hardware 0 24 December 2016 03:16
Final Fight on AMIGA 500+ (500 Plus), not 500! padremayi support.Games 55 09 March 2016 21:39
Possible to port Alien Breed 3D maps to Doom? (I know AB3D has features Doom can't) dex Coders. General 2 21 January 2012 23:06
GL Doom for Amiga fitzsteve support.Games 1 09 November 2010 13:52

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 14:44.


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