| |
Warlock Arkhinos Ratazmus
Account closed
Registered: May 2004
Posts: 23 |
Good coding practices ?
A few little points.
-I almost always coded my programmes to CRASH on NTSC systems, so when people say my code's bugged - you know it's not at all :D
-I posted on Lemon64 a few years back about using a coding convention whereby you reduce the use of bits, eg: use AND #$00 instead of LDA #$00, and after a jsr $e544 (I think, clear screen) the X-reg always was set to 1 on any 64 box I used - so i'd use that to setup interrupts. Somebody said that using less bits in the opcodes does'nt make the programme pack better ... heh right - you might want to check that.
I'm still coding for optimising - old habit I guess. |
|
| |
Majikeyric
Registered: Sep 2002
Posts: 83 |
I don't get the meaning of your post...
Use AND #$0 instead of LDA #$0 ?!!
What's the interest ? they all use 2 bytes.
If there was any interest in doing so everybody would do like this since ages.
You come from 80x86-land where you do : XOR reg,reg to clear a register ? :D
I don't think relying on internal rom calculations is a good coding practice, really...
|
| |
null
Account closed
Registered: Jun 2006
Posts: 645 |
you say you code for optimization, but isn't 'jsr $e544' a kernel routine, meaning you don't optimize all that well, seeing as you don't turn off the kernel?
------------------------------------
http://zomgwtfbbq.info |
| |
JackAsser
Registered: Jun 2002
Posts: |
Quote: you say you code for optimization, but isn't 'jsr $e544' a kernel routine, meaning you don't optimize all that well, seeing as you don't turn off the kernel?
------------------------------------
http://zomgwtfbbq.info
I usually switch all RTI:s to JSR:s and I favour LSR instead of CLD. I've found that those pack better with pucrunch, however if you use Exomizer you might want to use the STA,ADC and ROL instead of JMP,PHP and TAX.
I always also optimize Warlock! However I prefer using EOR when I try to be NTSC compatible. |
| |
Britelite
Registered: Dec 2001
Posts: 51 |
Quote: I usually switch all RTI:s to JSR:s and I favour LSR instead of CLD. I've found that those pack better with pucrunch, however if you use Exomizer you might want to use the STA,ADC and ROL instead of JMP,PHP and TAX.
I always also optimize Warlock! However I prefer using EOR when I try to be NTSC compatible.
Btw, ever tried to use SBC instead of ADC? SBC actually decreases bits while ADC gives more bloated results when crunching!
And thanks for the tip on using EOR for NTSC compatibility, it really solved a lot of problems for me. |
| |
Mace
Registered: May 2002
Posts: 1799 |
AND #$00 instead of LDA #$00 is interesting, just because of the weird way that it just works.
The fact that you save one bit is not at all interesting, this can hardly make a difference IMHO. If you say it does, I need evidence.
Also, my time is more valuable than online bytes or even floppy space, so I wouldn't want to spend time deciphering my unreadable code to save some bits.
Using presumed register values after calling a ROM routine is, like others already said, not at all good coding practice.
On top of it all, it is also important to think of what you are trying to optimise: speed or length?
In all, you are not making much sense, but I think the cynical replies of my fellow sceners already implied that ;) |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
If you wanna size-optimize, you should use a well written forth compiler, which actually represents most stuff in a more compact way compared to asm... ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
the question remains: how can i squeeze bits out of my opcodes? |
| |
Warlock Arkhinos Ratazmus
Account closed
Registered: May 2004
Posts: 23 |
My bad - curse of Apsergers (please look it up!), plus writing at some silly time in the morning does'nt help.
I tended to use the kernel vector to clear the screen before turning off the kernel as using that at the very beginning means I did'nt need to write the clear-screen loop.
eg; (off the top of my head, not done this for a decade)
sei
jsr $e544
stx $d019
dex
stx $01
stx $00 ;Used to check for Action Replay later
stx $d020
stx $d021
lda #$7f
sta $dc0d
and #$1b
sta $d011
etc.etc.etc.
Okay - I know the code is "less readable" this way, but I found that it compressed a lot better.
... proof you say ? Shazbar ! I'd need to code in 6502 again ! However, if you take it as read that the closer a file is to total entropy, the less it can be compressed - then checked the entropy of files using/not using bit-reduced code, then you'd see what I meant. Which is pretty much true :D
QUICK EDIT:
Normaly, 10 years ago before I knew I had Aspergers, i'd go off on one and start calling people names etc. But as I know i've got it - it gives me something to think about before replying and realise that nobody is really "having a go at me", just asking me to validate my claim.
Damned - where did all that anger go ? Or is it the pile of sedatives i'm on ? heh.
Oh, and if anyone wants an optimised PAQ8A variant for Intel CPU's - gimmie a shout ;) |
| |
JackAsser
Registered: Jun 2002
Posts: |
Quote: My bad - curse of Apsergers (please look it up!), plus writing at some silly time in the morning does'nt help.
I tended to use the kernel vector to clear the screen before turning off the kernel as using that at the very beginning means I did'nt need to write the clear-screen loop.
eg; (off the top of my head, not done this for a decade)
sei
jsr $e544
stx $d019
dex
stx $01
stx $00 ;Used to check for Action Replay later
stx $d020
stx $d021
lda #$7f
sta $dc0d
and #$1b
sta $d011
etc.etc.etc.
Okay - I know the code is "less readable" this way, but I found that it compressed a lot better.
... proof you say ? Shazbar ! I'd need to code in 6502 again ! However, if you take it as read that the closer a file is to total entropy, the less it can be compressed - then checked the entropy of files using/not using bit-reduced code, then you'd see what I meant. Which is pretty much true :D
QUICK EDIT:
Normaly, 10 years ago before I knew I had Aspergers, i'd go off on one and start calling people names etc. But as I know i've got it - it gives me something to think about before replying and realise that nobody is really "having a go at me", just asking me to validate my claim.
Damned - where did all that anger go ? Or is it the pile of sedatives i'm on ? heh.
Oh, and if anyone wants an optimised PAQ8A variant for Intel CPU's - gimmie a shout ;)
"Damned - where did all that anger go ? Or is it the pile of sedatives i'm on ? heh". Part of the growing up process, we all passes through those phases. :) |
| |
Warlock Arkhinos Ratazmus
Account closed
Registered: May 2004
Posts: 23 |
I'm actually proud that I tried to think before posting.
Part of it is growing up I guess - when I see my daughter play up like today, I have to think "ah crap, Karma !". The daddy side of me was upset that she was throwing things at people in the street - and part of me was "YEAH - YOU GO GIRL !!!". She does'nt get to see that side - but I know EXACTLY what she's going through as she's autistic too. Yeah, Karma !
Hey - if you think i'm a bad then you should see the caterpillar Ironfist has on his head :P I mean mohawk ;) |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Good coding/development practices? In no particular order...
Making code easier to read by commenting it and formatting it well.
Adding documentation, the goal being that if the coder fell under a bus then someone else could pickup the project.
Optimising code.
Revision control of all source and assets.
Maintain distinct reusable modules. This means writing something once, testing it then using it many times to avoid unnecessarily repeating work.
Unit tests. (Automatic preferred or manual result check if it's not possible or too time consuming.) For example a manual result check might looking at a closely packed sprite formation in a multiplexor to check all sprites are displayed. An automatic check would be something like a compression algorithm tested with lots of different data.
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
The best coding practice of them all is to actually finish what you are coding, and release some pretty daaaaaaaaaaaaaamn nice stuff! |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
A work of art is never finished while the artist is alive. :)
|
| |
drcode
Account closed
Registered: Mar 2009
Posts: 1 |
I have to agree that what mattered in the demos, was the fact that it looked cool, the effect or a variation was first one released and it was fun to make. It took some time to learn away from these principles. I expect that many of the industry wide coding practices can be applied to demo coding, but those are conflicting with those mentioned. Some routines were reusable (copy & paste) and there i can see a place to refactor some uggly code with some good coding practices. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Of course, some bits of code can't really be reused because they're cycle accurate with each changing scan line and triggering multiple effects. So in effect you're merging the code of several different ideas to create one bigger bit of code.
For example I'd love to be able to come up with a nice reusable maintainable way to create VIC display code where it can automatically schedule what VIC registers need to be changed at one cycle on a scan. But to write such a tool while possible would probably eat up much more time than I spend coding several of the effects.
But a lot of other code, even in demos, can be made modular and reusable. Like loaders, decrunchers, setup routines, 3D maths stuff etc. |
