The fall of amiga, just a thought :)

[saimo]

@ bloodline

I mean not using any of the Chipset features :-D

Ah, now it makes sense.
Anyway, the point is exactly that my library exploits the HW features and not just the CPU - this is why I brought it in this discussion, as an example of how the chipset can be useful.

No, I was not talking about your software.

Phew, being bashed that way after spending years of works is not nice :-D
But I would have accepted the criticism anyway, really :-)

I mean the Amiga chipset makes a very poor frame buffer. It has limited memory, limited resolution and useless bandwidth. Modern AGP cards make very good frame buffers :-)

Yep, the low bandwidth and all the rest are big downsides, but at least they push us until we bleed because of coding ;-)

I'm sorry, I haven't looked at your code.

You don't even need to: the distribution includes massive documentation (maybe a bit hard to read) ;-)

I thought about c2p myself and the only why I could do it was using the CPU alone.
My idea was to take an 8bit chunky buffer and turn it into 8 1-bit buffers that correspond the the bitplanes of the AGA amiga hardware, then coppy them over in one go to the chipram. It was very CPU intensive.

Yes, that's incredibly expensive.
But other coders have come up with amazing c2p engines... regards to them!

BTW: out of curiosity: do you (or anybody else) have any benchmarks of the best c2p engines around? I'd be very curious to see how mine compares to them...



saimo

[saimo]

@bloodline

:-) That is fun. But you did upgrade your CPU :-D

Huh! I missed this bit, before! - IE (don't blame me, I'm at the office ;-)) rendered everything until ":-)" and then stopped... a bug of XOOPS, maybe? :-?

Anyways: the library was started when I already had the card, but its main objective was CPU-free c2p so that even an unexpanded A1200 could do well with it - and given that it does offer CPU-free modes, the 020's little CPU time can be used for other things ;-)



saimo

[bloodline]

saimo wrote:
@bloodline

:-) That is fun. But you did upgrade your CPU :-D

Huh! I missed this bit, before! - IE (don't blame me, I'm at the office ;-)) rendered everything until ":-)" and then stopped... a bug of XOOPS, maybe? :-?

Anyways: the library was started when I already had the card, but its main objective was CPU-free c2p so that even an unexpanded A1200 could do well with it - and given that it does offer CPU-free modes, the 020's little CPU time can be used for other things ;-)



saimo

So how does your C2p work without the CPU then?

[saimo]

bloodline wrote:
So how does your C2p work without the CPU then?

Urgh! A full explanation would require 200 kb of text... in practice I should re-write the documentation :-o

Anyway... OK, here's the core: the resolution used is SHRES (that's why the right video HW is necessary) to reproduce the effect that CRTs use to draw coloured pixels. To do so, the appropriate bitplanes shifts, masking... well, a many settings ;-) are required... in practice, you make the same bitplane - to which you write as if it were a chunky buffer - overlap with itself...

Excuse me if I don't say more because it's 9.5 hours that I'm at the office and it's almost time to go back home ;-) Yet, if you are really curious, you can download the archive dev/misc/TCS.lha from Aminet and read the docs, in which I explain the technique step-by-step.
The archive includes a few demo programs to see it in action and you could also download dev/misc/TCS_demo.lha to see a "live" introduction to the system (it shows graphically the basics of how it works and some of the offered functionalities).
Finally, if you want to see a "serious" app exploiting that c2p, you should get hold of the MOM stuff at http://saimobvq.interfree.it/MOM/index.html - I'm mentioning this app also because I created it exactly with the spirit I've been talking about in this thread: the spirit of making effective, clean & lean things by banging nice HW (in practice the app is an emulator of a handheld machine I designed myself for this purpose).

- EDIT -
Ah, and don't forget that you need native video output + a 15 kHz-capable monitor (or, alternatively, a scandoubler which supports SHRES screens, but I dunno if it even exists)
- EDIT -

- EDIT 2 -
I've forgotten an important thing: I've tried the library on UAE 0.8.22 on my AmigaOne and it works, but graphics are not rendered correctly - I'd say that that version can't handle SHRES perfectly; dunno about 0.8.25... could anybody check it out, please?
- EDIT 2 -

- EDIT 3 -
I forgot the most import thing of all, too!  :-o
The idea of emulating a CRT is _not_ mine, but belongs to Fabio Bizzetti (AFAIK), who used it in his Virtual Karting.
Seeing that game really started a flow of thoughts that did not end until I figured out a way to implement the concept and exploit to the max (like the library does :-)).
- EDIT 3 -

Have fun and let me know!
saimo

[pwest]

Saimo: "Note that nowadays "making the most of the hardware" translates differently from the good ol' days: "

I agree.. I think that it is the explosive creative force that has drive aside the boundaries of computing power to give us a space in which to work. Now it's not so much a matter of getting past the boundaries in a clever manner, but of using what's inside the boundaries in a clever manner. The focus has shifted from expanding capabilities to using capabilities. All in all, something akin to any explosion ... a powerfully expansive sudden force which gradually fades and slows.

[saimo]

pwest wrote:
I agree.. I think that it is the explosive creative force that has drive aside the boundaries of computing power to give us a space in which to work. Now it's not so much a matter of getting past the boundaries in a clever manner, but of using what's inside the boundaries in a clever manner. The focus has shifted from expanding capabilities to using capabilities.

I like this way of putting it in words :-)
Yet, it's a pity that, in practice, the people that can _and_ want to use the wealth inside the boundaries are so little :-(
I'm tempted to say that the boundaries are enormous now (though, on second thought, maybe it's only a matter of muscles, not of architectural freedom), but, anyway, that would be no excuse for the countless lame things produced nowadays! :pissed:

saimo

[saimo]

@Waccoon

I wish I could quote, but this browser (handheld stuff) does not seem to be capable.

Anyway, about what you say until "WORSE": grab my hand and shake it, pal! :-)
I could not agree more!
I say the same things all the time, but most if the people look at me as if I was an alien :-(

As for triple buffering, a good implementation does perform VB synchronization... actually I think that without it is entirely spoiled of its meaning.

saimo

[Waccoon]

I wish I could quote, but this browser (handheld stuff) does not seem to be capable.

To quote, type "[ quote ]" (minus the extra space) to start the quote, then "[ / quote ]" to end the quote.  Just make sure it parses correctly.

As for triple buffering, a good implementation does perform VB synchronization... actually I think that without it is entirely spoiled of its meaning.

Lag is still a problem, but then, I dont' think in terms beyond 72 Hz and 64MB frame buffers.  I suppose if you can spare the memory.  I still prefer playing games on consoles, though.  Knowing the exact performance limits of your hardware is a very helpful (if lazy) thing.  ;-)

[saimo]

@Waccon

The problem is not writing the tags, but reporting the text ;-)

Lag? What lag, exactly?
In the scenario you mentioned above (i.e. machine so fast that it is able to render a frame in less than the time of a refresh), the triple buffering (a well done one) gives the same results of double buffering (of course it eats more memory and it's a bit more complicated).

- EDIT -
Yet, it is a better solution because it does not require assumptions on the power of the machine; besides the particular case already discussed, there is:
 - the case of the machine that _on average_ can render a frame in the time of a refresh: triple buffering allows to achieve an almost perfect refresh, without missing frames
 - the case of the machine that is even slower: triple buffering helps even more because there is no idle wait (i.e. the computing power is exploited to the max - this is the main aspect of triple buffering, which makes what has been said at the previous point possible) - not to mention that adding frame skipping becomes trivial, so keeping the "game cycles" synchronized with the video refresh is very easy.

[Indeed these two cases are the same thing, but I thought that exposing them this way would be clearer.]
- EDIT -

OK, the battery is dying, so see you later.

saimo