new amiga 500 doom like !

[sandruzzo]

Originally Posted by DamienD

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]

Originally Posted by Gorf

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...

[DamienD]

Originally Posted by sandruzzo

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.

[sandruzzo]

Originally Posted by DamienD

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

[DamienD]

Originally Posted by sandruzzo

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.

[Gorf]

Originally Posted by sandruzzo

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]

Originally Posted by sandruzzo

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]

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...

[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.

[saimon69]

Originally Posted by sandruzzo

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!

[b0lt-thrower]

Originally Posted by KK/Altair

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.

[KK/Altair]

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.

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.

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.

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).

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.

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.

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.

Ahh most excellent! Looking forward to seeing more demonstration soon. This is the kind of positive thinking I like to see!

Thanks!

[sandruzzo]

@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?

[Gorf]

Originally Posted by KK/Altair

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...

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

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.

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!

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]

Originally Posted by sandruzzo

@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

[sandruzzo]

@Gorf

That game look great, and very wast. Would be great to be able to choice level of details.

[hooverphonique]

Originally Posted by KK/Altair

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

[chb]

Originally Posted by hooverphonique

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.

[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?

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.

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.

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.

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.

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.

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.

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!

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.

[malko]

@KK/Altair : I am quite sure the last comment you have quoted was not for you