| |
Raistlin
Registered: Mar 2007
Posts: 680 |
Blog: All Border Double DYPP
So.. a few people had asked me about how I created certain effects.. I love blogging about code (I do this for my game-dev work, for example, and have done on-and-off for 10 years)... so...
https://c64demo.com/?p=19
The website needs a LOT of work, I know .. but for now it gives me a sandbed to upload these texts to.
Please let me know if you spot any mistakes, if you think I've overlooked explaining anything important, if you think I'm stupid and missed some obvious optimisation, etc...
Cheers! |
|
... 51 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Hence i said "almost". Sure there are cases like this. But very often this is not the case. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: The fact is, and I can tell you this with some certainty, C64 code generators won’t work on 90% of my parts because there are several layers of optimisations that simply couldn’t be done in 6510 in a decent timeframe.
It might sound like an excuse - I guarantee that it’s not. The best that I can imagine could be done is to tokenise some sections - but that’s certainly not going to reduce things enough to save a disk side. And without that, what’s the point? Who cares if a trackmo is 2.5 disk sides instead of 3?
I'm pretty sure interleaving timed raster code and a BOB plotter is quite straightforward, all you need is introduce a variable which keeps track of nr of cycles. then when treshhold is reached pad with nop's and write out the raster code, then goto 10. |
| |
Raistlin
Registered: Mar 2007
Posts: 680 |
Quote: I'm pretty sure interleaving timed raster code and a BOB plotter is quite straightforward, all you need is introduce a variable which keeps track of nr of cycles. then when treshhold is reached pad with nop's and write out the raster code, then goto 10.
It’s not that simple, no.. there are many optimisations that wouldn’t be easy to implement in a native codegen.. eg.:-
- maintaining whether each dest byte has already been written to (overlaps)
- whether ORA can be used for adjacent chars to save cycles
- whether the raster code is trashing A, X or Y and whether you currently need these for BOB plotting
- my codegen allows, under certain circumstances, for the BOB-plotter to leave a single cycle unused - but this needs to be cleverly wasted in the D016 code
- etc
By all means you could probably code -a- DXYCP or all border double DYPP using native codegen - but I doubt they would be as optimal. Prove me wrong or stop arguing, I say - the challenge is there. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
Quoting KrillOf course it is, but this isn't mutually exclusive with having run-time code generators. :) oh definitely, if I look from my own perspective, I write codegens for code, tables and even gfx often, but I only do it when it's straightforward.
I kinda understand Raistlin's point: the options are "spend a lot more time" or "just add another d64 in no time at all". both choices are valid :) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
There's situations where writing a codegen is a pain in the arse for sure. I for myself just wanted to point out to not generalize things, there is very often a good point to use a codegen. This also allows to be lazy on the ugly parts :-) |
| |
Sparta
Registered: Feb 2017
Posts: 49 |
I really hate to get involved in such a useless debate so I will limit my involvement to this single comment here.
Really, I just wanted to thank you all for appreciating Raistlin's effects (and thus, our demos) and the effort he is putting in his blog. This is clearly shown by the fact that the only argument against them here is using more disk sides than what you'd prefer. Thank you again!
Re: loaders. Bitbreaker, your loader is truly fantastic! As is Krill's loader and Spindle, of course. I could list numerous arguments for using any of the trackmo loaders here, but really, this is personal preference (and somewhat off-topic).
I love you guys all!
Cheers,
Sparta |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: It’s not that simple, no.. there are many optimisations that wouldn’t be easy to implement in a native codegen.. eg.:-
- maintaining whether each dest byte has already been written to (overlaps)
- whether ORA can be used for adjacent chars to save cycles
- whether the raster code is trashing A, X or Y and whether you currently need these for BOB plotting
- my codegen allows, under certain circumstances, for the BOB-plotter to leave a single cycle unused - but this needs to be cleverly wasted in the D016 code
- etc
By all means you could probably code -a- DXYCP or all border double DYPP using native codegen - but I doubt they would be as optimal. Prove me wrong or stop arguing, I say - the challenge is there.
since 6510 is turing complete, optimal codegen can be done, thats not a question. anyway at this complexity is rather pointless to make it natively you are right. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Oswaldanyway at this complexity is rather pointless to make it natively you are right. You can still apply a simple filter (separate opcode and operand streams) for better crunchiness of generated code, though. =) |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting Oswaldsince 6510 is turing complete, optimal codegen can be done, thats not a question.
The memory limitation for keeping track of state when generating optimal code is quite a bit lower when doing it at runtime, though. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Perplex, that's what swap disks are for!
runs |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
