English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 06 November 2019, 00:49   #221
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,640
Quote:
Originally Posted by DamienD View Post
Same old music; yes most definitely from you

What's that got to do with you trying to shove your ideas down the authors' of every new project???
It's so bad share idea? Maybe He can get something good, and come out with better new one for his project. I don't see what's the problem..
sandruzzo is offline  
Old 06 November 2019, 00:50   #222
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,640
Quote:
Originally Posted by Gorf View Post
i somehow doubt that ... since you need the Blitter and Copper to work at full time to draw the lines. After Denise DMA fetch for 4 bitplanes and Copper list (next in priority), what non cpu-blocking slots do you have left for the line-drawing?
I fear you need Blitter-nasty to get to the 1 million pixels per second, but then the CPU is totally blocked without FastRAM

Du you have some calculations here?
If you reduce screen size, you can gain a lot of cycles...
sandruzzo is offline  
Old 06 November 2019, 00:50   #223
DamienD
Global Moderator

DamienD's Avatar
 
Join Date: Aug 2005
Location: London / Sydney
Age: 43
Posts: 15,710
Quote:
Originally Posted by sandruzzo View Post
It's so bad share idea? Maybe He can get something good, and come out with better new one for his project. I don't see what's the problem..
Share ideas all you like, but as others have said it would nice if you actually had proof that your concepts worked and not just unfounded speculation...

I'm no coder, but it's clear that quite a few people in this thread are questioning your logic / technique.
DamienD is offline  
Old 06 November 2019, 00:55   #224
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,640
Quote:
Originally Posted by DamienD View Post
Share ideas all you like, but as others have said it would nice if you actually had proof that your concepts worked and not just unfounded speculation...

I'm no coder, but it's clear that quite a few people in this thread are questioning your logic / technique.
Did a demo that performed cp2 via blitter, otherwise I won't be here to share it. Btw I wont' go out of topic and bite space for this great project
sandruzzo is offline  
Old 06 November 2019, 00:56   #225
DamienD
Global Moderator

DamienD's Avatar
 
Join Date: Aug 2005
Location: London / Sydney
Age: 43
Posts: 15,710
Quote:
Originally Posted by sandruzzo View Post
Btw I wont' go out of topic and bite space for this great project
Last post from me on the subject; but I think you've already successfully done that...

Edit: your post after this one has been deleted sandruzzo, no more rubbish from you in this thread please.

Last edited by DamienD; 06 November 2019 at 01:03.
DamienD is offline  
Old 06 November 2019, 01:54   #226
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 869
Quote:
Originally Posted by sandruzzo View Post
Did a demo that performed cp2 via blitter, otherwise I won't be here to share it. Btw I wont' go out of topic and bite space for this great project
But you need to fill the data-register after each blitter draw via CPU - after every 16 pixels of a stripe ... that means you need every second slot free for the cpu ... together with Denise fetches and Copper you wouldn't come close to the theoretical 1 million pixels per second ... probably under 300.000 and than you did not make a single calculation ...

I would be happy, if you can prove me wrong, but I do not think this is going to bring any improvement and will only slow things down.
Gorf is offline  
Old 06 November 2019, 02:03   #227
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 869
Quote:
Originally Posted by sandruzzo View Post
If you reduce screen size, you can gain a lot of cycles...
no shit sherlock!

with about 300.000 pixels per second and 160*100 resolution and 4 bitplanes you are down to 4.6 frames per second and did not yet render anything ...
Gorf is offline  
Old 06 November 2019, 02:32   #228
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 869
I also think the timing to update the line-pattern by cpu would poof next to impossible, as you would need to draw a full 100 px line and change the pattern just in time every 16 pixels ... otherwise you would need to set up the Blitter to draw short 16px lines and the overhead for the setup would ruin everything speed wise...
Gorf is offline  
Old 06 November 2019, 02:41   #229
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 45
Posts: 1,310
Send a message via Yahoo to Samurai_Crow
The line mode planar texture mapper has been done. C2P is faster on an 030+ using the CPU and a 68000 doesn't have the oomph to pull it off either way. A blitter-based C2P is the right way to boost a 68000 as the demo this thread describes indicates.
Samurai_Crow is offline  
Old 06 November 2019, 05:24   #230
saimon69
J.M.D - Bedroom Musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 1,158
Quote:
Originally Posted by sandruzzo View Post
I allmost finished CHIP game, a simple puzzle game, but guess what? That guy disappeared...Allmost finished
I quote on that, since i did the music for it and still wait for feedback too :/

The guy is Zbigniew Po?oga - don't remember the nick nick is PPill and has its own thread in EAB - and since october me and Sandruzzo are waiting for feedback and levels; is a bit OT here but if someone has it in their acquaintances please let him know we need feedback!

Last edited by saimon69; 06 November 2019 at 06:13.
saimon69 is offline  
Old 06 November 2019, 08:30   #231
b0lt-thrower
Registered User
 
Join Date: Jun 2010
Location: US
Posts: 89
Quote:
Originally Posted by KK/Altair View Post
A perfectly reasonable solution I'm ashamed of not thinking of. Eats some chip memory, but I should manage.


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.
Ahh most excellent! Looking forward to seeing more demonstration soon. This is the kind of positive thinking I like to see! Just makes me giddy that this will all be on a stock A500.
b0lt-thrower is offline  
Old 07 November 2019, 02:49   #232
KK/Altair
Registered User

 
Join Date: Sep 2019
Location: Gdansk / Poland
Posts: 32
Quote:
I'll try to do a demo were i'll use blitter to do cp2 160x100 and see how much fps we can get.
I'm already doing C2P completely on Blitter. It requires two A+B->D passes to interleave the bits. The first pass also does transposition. Also once the chunky buffer is ready, CPU can start first blit and is immediately free to work on next frame - blitter driving and screen swap is done completely on interrupts. It does take some bus bandwidth, but feels like optimal way of doing things.

The 2x2 resolution is a design choice allowing hitting 10+ FPS required for an action game. While this saved one pass by ordering bits, the Blitter still copies all 320 pixels (which I used for dithering). It does benefit from doubling scanlines, though, as it halves amount of work.

I appreciate the creative thinking in the direction of Blitter line drawing (without such type of thinking my game wouldn't have existed), but this way Blitter can only move one bit every 6 or 8 cycles. In my current technique Blitter transfers 16 pixels every 6 cycles, and even though two such passes are required, it's still about 8x as fast as line drawing could be.

Anyway, the C2P isn't any major bottleneck for me right now. If I should name any, it would be (vertical) scanline drawing setup. Not the actual copying of pixels, but deciding what, where and how pixels should be scaled and copied.

Quote:
Instead of telling others how to program / manage their games; let's see yours
All ideas are welcome. I'm looking for best way of handling every single aspect of this engine, so I'm glad to hear and consider any ideas which could improve things.

Quote:
The point is: why doing somenthing (I'm not talking about this project) that don't suits Amigas' HW well and having an not so visual good outcome?
Because doing things other people perceive as impossible is simply exciting.
And don't judge visuals by modern standards.

Quote:
After Denise DMA fetch for 4 bitplanes and Copper list (next in priority), what non cpu-blocking slots do you have left for the line-drawing?
The timing here wouldn't really be different than what I have now, and the CPU does quite fine (unless nasty bit is set). Blitter and CPU will always compete unless the bus is completely free at the moment (in which case the CPU will move to the cycles the Blitter can't use).

Quote:
I fear you need Blitter-nasty to get to the 1 million pixels per second, but then the CPU is totally blocked without FastRAM
Agreed. And when the Blitter is interrupt driven, the CPU remains the only limiting factor (Blitter processing only adds delay), so nasty bit lowers the framerate. I even wished there was a "Blitter nice" bit that would make Blitter give away every possible bus cycle whenever CPU needs it.

Quote:
Share ideas all you like, but as others have said it would nice if you actually had proof that your concepts worked and not just unfounded speculation...
No problem with that. Once the idea is in and it looks plausible, I can do basic calculations myself. And test the technique if it looks promising.

Unfortunately, basic estimations make line drawing C2P look order of magnitude slower than my current solution, so that all for it. Unless I completely misunderstood something about this technique.

Quote:
I also think the timing to update the line-pattern by cpu would poof next to impossible
Sorry... your CPU is away, already drawing the next frame.

Quote:
Ahh most excellent! Looking forward to seeing more demonstration soon. This is the kind of positive thinking I like to see!
Thanks!
KK/Altair is offline  
Old 07 November 2019, 03:56   #233
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,640
@KK/Altair

Thanks Mate, I appreciate a lot your attitude. Have you ever consider to do some kind of "Low-details gfx mode", in order to have walls without textures and go faster on A500?
sandruzzo is offline  
Old 07 November 2019, 04:36   #234
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 869
Quote:
Originally Posted by KK/Altair View Post

I appreciate the creative thinking in the direction of Blitter line drawing (without such type of thinking my game wouldn't have existed), but this way Blitter can only move one bit every 6 or 8 cycles. In my current technique Blitter transfers 16 pixels every 6 cycles, and even though two such passes are required, it's still about 8x as fast as line drawing could be.

The timing here wouldn't really be different than what I have now, and the CPU does quite fine (unless nasty bit is set). Blitter and CPU will always compete unless the bus is completely free at the moment (in which case the CPU will move to the cycles the Blitter can't use).
My post was actually a question to sandruzzo and hits line-drawing proposal..

As you answered him: "but this way Blitter can only move one bit every 6 or 8 cycles" - so this wouldn't leave enough sloth left for the cpu, if you want to draw 160*100 pixels this way...

Quote:
Agreed. And when the Blitter is interrupt driven, the CPU remains the only limiting factor (Blitter processing only adds delay), so nasty bit lowers the framerate.
exactly

Quote:
I even wished there was a "Blitter nice" bit that would make Blitter give away every possible bus cycle whenever CPU needs it.
to be able to change DMA priorities would in deed be a nice feature ... it was intended for AAA as far as I know.

Quote:
Unfortunately, basic estimations make line drawing C2P look order of magnitude slower than my current solution, so that all for it. Unless I completely misunderstood something about this technique.
I would not say order of magnitude, but still significantly slower.

@sandruzzo: but I am happy if you poof us wrong here!

Quote:
Sorry... your CPU is away, already drawing the next frame.
yes ;.)
after some thinking: one could set up a extensive Copper-list to feet the data register for the line drawing ... that would make the timing manageable, but the cpu would than need to fill the complete screen-data into that list and the list would be at least double the size of you screen and Copper-fetches would use up all available slots ... so this is never going to work without real FastRAM.
Gorf is offline  
Old 07 November 2019, 04:40   #235
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 869
Quote:
Originally Posted by sandruzzo View Post
@KK/Altair

Thanks Mate, I appreciate a lot your attitude. Have you ever consider to do some kind of "Low-details gfx mode", in order to have walls without textures and go faster on A500?
look up the game "behind the iron gate"

here is a video:
[ Show youtube player ]


a) it has already be done
b) without textures its not doom-like anymore
Gorf is offline  
Old 07 November 2019, 07:05   #236
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,640
@Gorf

That game look great, and very wast. Would be great to be able to choice level of details.
sandruzzo is offline  
Old 07 November 2019, 11:13   #237
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,001
Quote:
Originally Posted by KK/Altair View Post
I even wished there was a "Blitter nice" bit that would make Blitter give away every possible bus cycle whenever CPU needs it.
Consider the fact that the cpu is never idle, and most A500's have no real fast ram - such a 'nice' bit would not be very useful then
hooverphonique is offline  
Old 07 November 2019, 12:44   #238
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 197
Quote:
Originally Posted by hooverphonique View Post
Consider the fact that the cpu is never idle, and most A500's have no real fast ram - such a 'nice' bit would not be very useful then
It actually could be quite useful to maximize memory bandwidth usage. Consider you have a blit running and finishing during bitplane dma - it will steal cycles from the CPU that the CPU could have used and leaving free memory cycles during the blank part that the CPU cannot use, but where blitter and CPU could work in parallel.

One can try to use alternative blits that have idle cycles to get closer to having a blitter nice bit - e.g. using a BC->D blit instead of AB->D; the latter one should contain an idle cycle for every 3 memory cycles according to the diagram in the HRM errata. That's of course only a hack and has other limitations that might make it the inferior option.

Last edited by chb; 07 November 2019 at 12:49.
chb is offline  
Old 07 November 2019, 13:45   #239
KK/Altair
Registered User

 
Join Date: Sep 2019
Location: Gdansk / Poland
Posts: 32
Quote:
Thanks Mate, I appreciate a lot your attitude. Have you ever consider to do some kind of "Low-details gfx mode", in order to have walls without textures and go faster on A500?
I think this won't speed up things enough to make this worth. I'd expect only 20-25% speed increase and that would still require serious engine changes (a separate rendering path with all texture-related code removed). And there are engines which do much better job at non-textured rendering already.


Quote:
so this wouldn't leave enough sloth left for the cpu, if you want to draw 160*100 pixels this way...
Exactly the opposite. Because the whole operation is 8x slower, CPU would no longer be a bottleneck.


Quote:
I would not say order of magnitude, but still significantly slower.
8x is already close enough to "order of magnitude". And I'm sure adding setup cost for all the blits will get to that 10x quite easily.


Quote:
after some thinking: one could set up a extensive Copper-list to feet the data register for the line drawing ... that would make the timing manageable
Copper is already busy doubling scanlines, so you have to account for that. And that means that your C2P routine will have to be synchronized to particular scanlines (i.e. you can't start C2P mid-frame), which will sync your framerate to full frames - slowing everything at least 10-20% (based on current performance).


My C2P implementation right now can be triggered at any moment, and when it finishes it will schedule screen swap on next vsync. And there are two chunky buffers, which means that CPU can fill them and commit to C2P as fast as it can without taking any vsync into consideration. So, if you are several miliseconds late to fit your rendering in 4 frames, you don't loose rest of that 5th frame waiting.


Quote:
look up the game "behind the iron gate"



a) it has already be done
b) without textures its not doom-like anymore
I could totally imagine Doom-like game in this style, with various heights and angled walls.


Quote:
Consider the fact that the cpu is never idle, and most A500's have no real fast ram - such a 'nice' bit would not be very useful then
Exactly. But right now, the CPU requires 3.5-5.0 vsyncs to render a frame, while the Blitter finishes C2P in just one or two (didn't measure). If there was a way to make CPU faster at the cost of Blitter speed, it would make processing more parallel at the cost of latency (which might make the game unplayable, but that's another question).

Basically, when starting a frame CPU and Blitter work together competing for cycles. Then Blitter finishes the work, CPU remains alone, and some cycles are wasted - during horizontal & vertical overscan when display is not fetching and when CPU performs operations not requiring memory access.


Quote:
One can try to use alternative blits that have idle cycles to get closer to having a blitter nice bit - e.g. using a BC->D blit instead of AB->D; the latter one should contain an idle cycle for every 3 memory cycles according to the diagram in the HRM errata. That's of course only a hack and has other limitations that might make it the inferior option
Great suggestion! I'm quite sure I could live with BC->D as well. But are you sure the Blitter doesn't get the bus on the extra cycle?


Thanks for all the suggestions like this. This thread is really useful!



Quote:
I am sure someone would want to provide you with graphics if they see that you actually willing to finish a project.
Right now I'm fine using FreeDoom assets, so as soon as I'll be able to open the game for modding, people will have the chance to do this by themselves without having to rely on me for anything.
KK/Altair is offline  
Old 07 November 2019, 14:37   #240
malko
Ex nihilo nihil

malko's Avatar
 
Join Date: Oct 2017
Location: CH
Posts: 2,328
@KK/Altair : I am quite sure the last comment you have quoted was not for you
malko 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 15:50.


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