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! :)