Pacman4K Source Code

[Mr SQL]

1 hour ago, RevEng said:

Warnings aren't friendly errors that allow you to build your ambiguously or contradictingly defined code. Warnings are reserved for things that are technically valid syntax, which otherwise may be problematic.

 

If you're expecting on the fly typing, type conversion, and other fiddling behind the scenes, check out a higher level language like cc65. Assembly language is supposed to be precise, by design.

It depends -

I agree warnings are supposed to be reserved for things like technically valid syntax which could be problematic.

 

But this isn't what we see in the real world, the 30 year SQL Server codebase is a good example where well meaning warnings have been added and escalated to be show stoppers that help junior and intermediate programmers, but break complex code beyond the understanding of the author of the warnings that had nothing wrong with it. We use work arounds to resolve these issues when they make it into a release and when identified, they are often reverted via hotfixes.

 

1 hour ago, Andrew Davie said:

a) use a version of dasm that allows it, and stick to it

b) maintain a local version of dasm and keep that up to date with only the changes they approve/like.

b) fork dasm and re-implement the version you like.

I'm going to buy a vowel, the other codes are ambiguously defined  

1 hour ago, Andrew Davie said:

I was always taught, and firmly believe, that with any assembler/compiler you treat warnings as errors.

I think only errors should be treated as errors or else we loses the severity which is very useful for warnings; some warnings should just be ignored all of the time and some can be ignored some of the time.  

 

[+Andrew Davie]

14 minutes ago, Mr SQL said:

 

I'm going to buy a vowel, the other codes are ambiguously defined  

 

 

Is that a warning, or are you pointing out an error?  Let's ignore it.

 

[+Pat Brady]

6 hours ago, Mr SQL said:

No backwards compatible has nothing to do with error checking unless you escalate an error (change the category) so that the programs will no longer compile, adding additional warnings isn't a problem. I write IDE's and compilers and I think this is very important particularly when the library codebase becomes large.

 

Unless you can personally track down all of the prior source code downloads and mirrors and correct them all too then it makes the code examples more difficult to use for having to "correct it" first so that warnings that have been escalated to show stopping errors can be resolved so they no longer stop the show.

 

I don't think you realize that is what you are arguing; nobody is against compiler warnings, just the idea that some of them should be escalated into show stoppers that break the binary.

 

That's what I'm questioning. "Why do that?" there's no real answer besides pedantic reasoning and there are many compiler warnings to choose from so which one do you think should be turned into a show stopper next?  

 

 

Everybody here understands your position, my position, and the distinction between errors and warnings, so this seems like a great place to stop arguing.

[Mr SQL]

5 hours ago, Pat Brady said:

 

Everybody here understands your position, my position, and the distinction between errors and warnings, so this seems like a great place to stop arguing.

Not everyone agrees there should be a distinction between errors and warnings or we wouldn't be having the discussion.

 

Some programmers like Andrew feel very strongly they should be treated the same as an exercise in learning proper form (see his post just above) and RevEng explained the warning was escalated to an error similarly with the understanding it would break existing code.

 

I think it's extreme to reclassify an error as a warning, moreso to reclassify all warnings as errors but I understand in Andrew's case he is doing extreme programming exercises to make it more challenging (try that exercise - it's hard I would be recoding forever!)

 

[+Andrew Davie]

1 hour ago, Mr SQL said:

I think it's extreme to reclassify an error as a warning, moreso to reclassify all warnings as errors but I understand in Andrew's case he is doing extreme programming exercises to make it more challenging (try that exercise - it's hard I would be recoding forever!)

 

 

That is not my motivation, no.

 

In large projects, the tendency, for individuals and teams both, is to ignore warnings - particularly when they are from other peoples' code. Once you start doing that - inevitably you end up with absolutely heaps of warnings - pages and pages of them scroll by during a compile. And of course, nobody bothers checking them because the assumption is that it's been OK so far, so they can safely be ignored. Warnings are there for a reason. They can flag potential future logical errors at runtime which will not be picked up by the compiler. They can point to sloppy code, incorrect code, to inefficient use of resources and much more. Before you know it you have thousands of warnings in your large project and nobody, ever, looks at the warnings. Because that one important warning is buried amongst hundreds or thousands of "unimportant" ones.  And your coding life is much harder and more error prone.

 

Treating warnings as errors is actually a lazy way out. I like to do as little work as possible. You use the compiler to help you write decent, safe, reliable and correct code. It takes little effort, as you go along, to correct the warnings. When you have zero warnings in your code, and you add more code and there's a warning - well that stands out. You and/or your team actually pay attention to the warning and ask not only why the warning, but also analyse why your code has to be written in such a way that it is ambiguous... inefficient... or incorrect. Whatever the case may be. There's very rarely a reason for a warning to be required in the code.  And some warnings point to serious coding errors.  For example, 
 

class A {
private:
  Obj sample;

public FnA(Obj sample) {
    sample = sample;
}
}

Ignore my screwy syntax; it's been a while since I programmed this language.

But the point is, the line "sample=sample" would be flagged as a warning by your compiler.  Is that line in error?  You probably meant "this.sample = sample" and instead of FnA setting it -- it's left at null, or uninitialised.  But it will compile perfectly OK, and if you routinely ignore warnings you won't catch these simple mistakes. This can lead to serious errors down the track. Your program probably won't work at all.  But your compiler flags this, and it's easy to spot the "error" even though it's not a "syntax error", is it? It's a warning.

 

So, now bury these sorts of helpful warnings amongst a thousand other warnings which you have ignored as you've been developing the project. Now compiler warnings are next to useless to you. 

You appear to have interpreted my approach as extreme programming exercises but in fact I consider this all (treating warnings as errors) as one facet of lazy, defensive programming.  Along with treating warnings as errors and fixing every single one of them, I also pepper my code with asserts just to make sure that things are what they are expected to be. And I catch coding/logic errors absolutely as early as possible both in the development cycle and at runtime.

I don't treat warnings as errors because I'm a glutton for punishment. I do it because it makes better programs.



 

[Thomas Jentzsch]

1 hour ago, Andrew Davie said:

In large projects, the tendency, for individuals and teams both, is to ignore warnings - particularly when they are from other peoples' code. Once you start doing that - inevitably you end up with absolutely heaps of warnings - pages and pages of them scroll by during a compile. And of course, nobody bothers checking them because the assumption is that it's been OK so far, so they can safely be ignored. Warnings are there for a reason. They can flag potential future logical errors at runtime which will not be picked up by the compiler. They can point to sloppy code, incorrect code, to inefficient use of resources and much more. Before you know it you have thousands of warnings in your large project and nobody, ever, looks at the warnings. Because that one important warning is buried amongst hundreds or thousands of "unimportant" ones.  And your coding life is much harder and more error prone.

/signed

 

1 hour ago, Andrew Davie said:

You appear to have interpreted my approach as extreme programming exercises but in fact I consider this all (treating warnings as errors) as one facet of lazy, defensive programming.  Along with treating warnings as errors and fixing every single one of them, I also pepper my code with asserts just to make sure that things are what they are expected to be. And I catch coding/logic errors absolutely as early as possible both in the development cycle and at runtime.

I don't treat warnings as errors because I'm a glutton for punishment. I do it because it makes better programs.

...and better programmers.

 

 

[Mr SQL]

10 hours ago, Andrew Davie said:

 

In large projects, the tendency, for individuals and teams both, is to ignore warnings - particularly when they are from other peoples' code. Once you start doing that - inevitably you end up with absolutely heaps of warnings

Yes exactly - this is why I thought your idea to treat them all as errors could only be an extreme training exercise.

 

Just one warning escalating into an error and breaking code can cause havoc but imagine if they all really did became errors?

 

Instead of becoming easier no one would ever finish a project they would be so busy hunting down errors that were just warnings in the last build.

 

10 hours ago, Andrew Davie said:

...if you routinely ignore warnings you won't catch these simple mistakes

Really? But I've never looked at warnings except when they are escalated to errors either intentionally or by mistake  (both types often get resolved with hotfixes). 

 

9 hours ago, Thomas Jentzsch said:

... I do it because it makes better programs.

 

Well there are many ways to program effectively and I prefer to use Tron; I run a trace when functionality breaks rather than waste time on every single warning on a large project; there's not enough time for that.  

 

10 hours ago, Andrew Davie said:

Along with treating warnings as errors and fixing every single one of them...

That sounds like it would work great in academic examples at University along with the boiler-plate example for students, but there is simply no time to peruse warnings in large professional projects as you've pointed out, only the show stopping errors and hot-spots get attention.

 

Debro's 4K Pacman is a very impressive project, I think "blinking dot" in 128 bytes would be the right concept and footprint for your academic exercise.

 

If there's a large project where no warnings exist, tell me more about it's characteristics - what type of project is it? 

 

[CapitanClassic]

It is not the responsibility of the maintainers of the build tools to make sure that all old software still compiles. Especially in this case, where the previous version was incorrectly handing a situation that should be an error. 
 

It is the responsibility of the Game Preservationists to make sure that the source code, the binaries, the tools, and the environments used to create the games are archived in such a way that someone could use that archive to recreate the game exactly as it was when originally produced. If Debro wasn’t being so kind to actually update the code to be correct, at a minimum the source code should contain comments containing the version of dasm (and the command line arguments) used to build the binary. 

 

[Mr SQL]

4 hours ago, CapitanClassic said:

It is not the responsibility of the maintainers of the build tools to make sure that all old software still compiles.

 

On 10/23/2020 at 11:55 AM, Andrew Davie said:

That's interesting, so much for backwards compatibility.

 

4 hours ago, CapitanClassic said:

Especially in this case, where the previous version was incorrectly handing a situation that should be an error. 

On 10/25/2020 at 7:31 AM, Andrew Davie said:

The earlier version allowed incorrect code, but did its best to produce correct results.

 

4 hours ago, CapitanClassic said:

It is the responsibility of the Game Preservationists to make sure that the source code, the binaries, the tools, and the environments used to create the games are archived in such a way that someone could use that archive to recreate the game exactly as it was when originally produced.

I've helped preservationists with source code, binaries, games and development tools I built in the 80's. So has Andrew and his ideas above reflect similar perspective I am inclined to agree with, though I find your perspective interesting; why do you think it's not the responsibility of the maintainers of the build tools to keep them backward compatible?

 

4 hours ago, CapitanClassic said:

... update the code to be correct, at a minimum the source code should contain comments...

 

Why do you believe this?

 

There are many productive ways to program and escalating warnings to errors and breaking backward compatibility is difficult to justify, because it affects some programming models more than others. 

 

I like comments, but I think that programmers who feel the code is all that is necessary (the code is the comments) have an equally valid perspective. 

 

[+SvOlli]

On 10/29/2020 at 3:55 AM, Andrew Davie said:

Python redefined the print function between version 2 and 3.  Totally incompatible and it broke absolutely heaps of code. And rightly so - it was totally the right thing to do. The print in version 2, for example, was a poor implementation/design. No thoughts of "backward compatibility" there. Is Python 3 better than Python 2.  Yes, heaps.  Likewise, dasm has fixed this issue so that incorrect values are flagged as the errors they are. Is the latest dasm better than the older versions. Oh yes, heaps and heaps.

Then please reflect that in the version number. Most probably this change will not justify a dasm 3.0, it will at least justify a version 2.21.0, instead of bumping up to 2.20.14.

[+Andrew Davie]

1 hour ago, Mr SQL said:

So has Andrew and his ideas above reflect similar perspective I am inclined to agree with, though I find your perspective interesting; why do you think it's not the responsibility of the maintainers of the build tools to keep them backward compatible?

 

Don't misrepresent my views.  Backward compatibility is very important. But correct code is even more important. By a long margin.

My reaction that you selectively quote was on first finding that the code would not compile. But once I understood the cause/reason, and had a think about what this meant - I clearly stated that the code should be fixed, not dasm.  I'm done arguing this point, we have now all had our say.

 

[CapitanClassic]

7 hours ago, Mr SQL said:

 

Why do you believe this?

 

There are many productive ways to program and escalating warnings to errors and breaking backward compatibility is difficult to justify, because it affects some programming models more than others. 

 

I like comments, but I think that programmers who feel the code is all that is necessary (the code is the comments) have an equally valid perspective. 

 

Quote

at a minimum the source code should contain comments containing the version of dasm (and the command line arguments) used to build the binary. 

Why dont you think source code should at a minimum contain the version of the build tools used to create the binary? Not documenting that isnt a valid perspective. 

[Mr SQL]

6 hours ago, Andrew Davie said:

Don't misrepresent my views.  Backward compatibility is very important.

 

I quoted you because you believe backward compatibility is an important responsibility of the maintainers of the build tool, which Captain Classic did not understand.

6 hours ago, Andrew Davie said:

But once I understood the cause/reason, and had a think about what this meant - I clearly stated that the code should be fixed, not dasm.

I thought your subsequent opinion had academic influence from being a professor, it sounded to me like an ideal University coding model that cannot be used in the real world due to time constraints (ie an academic exercise).

22 minutes ago, CapitanClassic said:

Why dont you think source code should at a minimum contain the version of the build tools used to create the binary? Not documenting that isnt a valid perspective. 

I cannot say that both perspective aren't valid because I know great programmers who have both and have seen them applied.

 

I agree with Andrew it's time for a context change - you're both free to explain or comment on my coding model if you wish too, but it might be more fun to talk about Pac-Man now  

 

So for the playah's and playah-coders enjoying this thread who's down for Other Peoples Pacmen?

 

I've got over two dozen Pacmen on the new Game Modem and I enjoy them all, Debro's is one of the best:

 

 

There are some great coders on this thread so build your custom Pacman if you haven't already and share them!  

 

I like all of the variations and nuances of the Pacman genre and the individuality of the authors that shine through in the different ports, the original Pacman by @Tod frye is also one of my favorites and here I am setting one of the Game Modem high scores with the awesome 8K reimplementation of Tod's codebase modified by @Nukey Shay:

 

 

[+Al_Nafuur]

15 minutes ago, Mr SQL said:

There are some great coders on this thread so build your custom Pacman if you haven't already and share them!  

 

I like all of the variations and nuances of the Pacman genre and the individuality of the authors that shine through in the different ports, the original Pacman by @Tod frye is also one of my favorites and here I am setting one of the Game Modem high scores with the awesome 8K reimplementation of Tod's codebase modified by @Nukey Shay:

 

 

Nice transparent case for the PlusCart. How did you build it?

Can you post some pics in the PlusCart thread?

[alex_79]

7 hours ago, Andrew Davie said:

Don't misrepresent my views. 

Twisting other people's words, not providing evidence, moving to another argument when shown to be wrong, are some of the reasons he's been put in the ignore list by most of those who had the misfortune to embark in a discussion with him.

 

For unknown reasons, if someone finds a bug in his code, he consider that as an insult and a personal attack, so that might explain his aversion to this bug fix in dasm.

 

In the past, some changes in Stella behavior revealed missing initialization in some of his games, and as a result he totally freaked out, spamming threads by affirming that the emulator was buggy and, when proved wrong, coming out with the absurd explanation, that in fact he programmed the games that way on purpose, to support a toy console running a lousy emulator...

Edited October 30, 2020 by alex_79

[Mr SQL]

7 hours ago, alex_79 said:

Twisting other people's words, not providing evidence, moving to another argument when shown to be wrong, are some of the reasons he's been put in the ignore list by most of those who had the misfortune to embark in a discussion with him.

I haven't twisted anyone's words, and you're neither ignoring nor contributing to the conversation in a friendly way.

 

Why not share your view for discussion instead of throwing insults or better yet write a Pacman, I think you're a very good programmer!

7 hours ago, alex_79 said:

For unknown reasons, if someone finds a bug in his code, he consider that as an insult and a personal attack, so that might explain his aversion to this bug fix in dasm.

Can you provide an example? I think you must have misunderstood.

7 hours ago, alex_79 said:

In the past, some changes in Stella behavior revealed missing initialization in some of his games, and as a result he totally freaked out, spamming threads by affirming that the emulator was buggy and, when proved wrong, coming out with the absurd explanation, that in fact he programmed the games that way on purpose, to support a toy console running a lousy emulator...

You misunderstood this clearly, but what you say about my explanation is otherwise accurate - 

 

Here's my interpretation:

 

What you call a "lousy toy console running an emulator" is the Atari Flashback Portable Console which is pretty cool for having an SD card to load games, and many players like this console.

 

It doesn't support the SuperCharger format so I wrote a cross compiler to allow games written for the SuperCharger to be cross compiled for the CBS RAM Plus format (7K and 256 Bytes of RAM). If you compare the two entries at the top and bottom of my Game Modem pacman folder screenshot, you'll see Tunnel Runner and Escape from the MindMaster, both amazing 3D pacmen. These 3D pacmen were a large part of inspiration to create the cross compiler that turns SuperCharger games into CBS RAM games, because they illustrate see how close the respective capabilities of the expansion technologies were.

 

I think it shouldn't seem an absurd explanation for abstracting the hardware for a cross-compiler but a requirement for it rather (the abstraction layer).

 

Why not share your perspective never having written a cross compiler in lieu of throwing the personal insults while pretending to ignore me?

 

That just looks like a hit and run...  

 

 

[+Stephen]

I so preferred the mean reptile represented here

 

[CapitanClassic]

3 hours ago, Mr SQL said:

I haven't twisted anyone's words, and you're neither ignoring nor contributing to the conversation in a friendly way.

You twisted my words.

[alex_79]

9 hours ago, Mr SQL said:

I haven't twisted anyone's words, ...

You did in every single post of this thread. You distort or just plain invent what other said, and then use that to support your thesis.
And it takes efforts to selectively quote small portion of a phrase (just a few words more and it would be clear what the original poster meant) and presenting it out of context so to completely misrepresent other people's view. That's clearly deliberate. And shows a complete lack of respect towards the people here who invested time to have a reasoned discussion with you. You're insulting them.
The end result is that the other interlocutors soon realize how worthless is to continue this single-way "discussion" and give up. I guess in your mind your think that you "won" by resignation of the opponent. I hope you're proud of it.

For example, there was absolutely no warning that has been escalated to error. No one ever said that. And a previous version of dasm has been posted in this very same thread, so you could have tried to compile the source and verify your facts without much effort. You evidently felt it was better to spend your time enriching your "discussion" with random images and youtube videos. I guess you consider supporting your point with facts an "academic exercise", and you made pretty clear how much a negative connotation that has in your mind.

I think the dasm mantainers gave very reasonable motivations for the addition of this error check, and explained why it was worth sacrificing a bit of backward compatibility with that fix. I don't have anything to add and only posted because I was yet again pissed off by you trying to make a fool of people investing time discussing with you. I have not desire to talk about any subject with you either. I did it once and that was enough. The problem is that your comments are visible when someone quote them even if you're on my ignore list (the only and one, in more than 20 years of me participating in forums on internet!), and unfortunately you seem to always show up in threads I'm more interested in. As a result I more and more abstain from commenting in those threads and I lost quite a bit of interest in visiting the forums.

What you do is not discussing, as from the beginning you have absolutely no intention to listen to what other people have to say nor to change your position if evidence proves you wrong. That's a sermon rather than a discussion. And I'm not interested in that.

 

I apologize to everyone else for going off-topic and I won't derail the thread any further.

 

[Thomas Jentzsch]

He's on my (short) ignore list for quite some time too. Well deserved back then and obviously still today.

 

Like you said, unfortunately "Ignore User" doesn't ignore quotes.

 

@Albert Is there a chance that this can be added?

Edited October 31, 2020 by Thomas Jentzsch

[Mr SQL]

On 10/29/2020 at 11:37 PM, CapitanClassic said:

It is not the responsibility of the maintainers of the build tools to make sure that all old software still compiles.

 

13 hours ago, CapitanClassic said:

You twisted my words.

Alright well what did you mean then?

 

@Albert please encourage TJ and Alex to join the conversation in a friendly way. It's OK for programmers to have different perspectives but not to throw insults when someone does not agree a perspective is the one best way. 

 

I think that the different builds of Arkanoid Airhead running black, white and Rainbow on the different Atari platforms represent interesting ideas and ways of thinking for interpreting how CBS RAM should function and no one should be angry that those different developers have different ideas and in this case, I carefully wrote code to accommodate the three different ways of thinking and still produce a working ROM. 

 

It would be more fun if both programmers participate and join the conversation or at least be tolerant enough of other ideas to let others enjoy them. Close your mind, miss the fun  

 

I'm going to post some pics of my transparent case I built for the Game Modem on the PlusCart thread, I built it to match the transparent AtariMax cart for my 800XL, and I'm only responding to friendly posts on this thread going forward, like this one:

16 hours ago, Stephen said:

I so preferred the mean reptile represented here

 

Awesome double true  

 

 

[CapitanClassic]

I like to play a game I call SoL.

 

My original quote, and selective quote below (bold portion missing)

Quote

at a minimum the source code should contain comments containing the version of dasm (and the command line arguments) used to build the binary. 

... update the code to be correct, at a minimum the source code should contain comments...

 

Quote

Why do you believe this?

 

There are many productive ways to program and escalating warnings to errors and breaking backward compatibility is difficult to justify, because it affects some programming models more than others. 

 

I like comments, but I think that programmers who feel the code is all that is necessary (the code is the comments) have an equally valid perspective. 

 

Your comment only makes sense If you ignore the full quote. Even after I clarified, by including the entire quote, and clearly stated I was specifically taking about documenting build tools used to create the game, you seems to be oblivious.

 

Quote

I cannot say that both perspective aren't valid because I know great programmers who have both and have seen them applied.

So take your pick. 
 

P.S. I will leave it as an exercise for the reader to determine how my other quote was twisted.  

Edited October 31, 2020 by CapitanClassic

[Mr SQL]

1 hour ago, CapitanClassic said:

Your comment only makes sense If you ignore the full quote. Even after I clarified, by including the entire quote, and clearly stated I was specifically taking about documenting build tools used to create the game, you seems to be oblivious.

 

Quote

I cannot say that both perspective aren't valid because I know great programmers who have both and have seen them applied.

So take your pick. 
 

P.S. I will leave it as an exercise for the reader to determine how my other quote was twisted.  

CaptainClassic consider that the programmer who prefers no comments has also written an awesome pacman and is in my pacman folder on the Game Modem too.

 

Regarding the ... quote I didn't agree with "update the code to be correct" since it compiled before the change and RevEng acknowledged the change was intentionally "breaking" code. From my perspective if the code builds a binary, particularly a pacman binary, it is correct. 

 

Like the pacman programmer who prefers no comments I simply prefer not to use warnings so escalating any of them to break code affects my coding model more. Some programmers find warnings more helpful and some prefer to treating some warnings or even all of them as errors. That's something new I learned on this thread which is pretty cool.

 

Edit: Here's an example of sharing something new in Defender III and WARPDRIVE, but Alex follows me with more insults the games are running at half the frame rate, simply because of the other thread he linked where another game that looked similar ran at half the frame rate. That game and your SOL ignore game look like e-stalking to me, please knock it off and discuss technology like a normal  person or play Atari games instead of forming a circle.  

 

 

 

Edited November 1, 2020 by Mr SQL
example of something new

[CapitanClassic]

Oblivious. Ignore.

[CPUWIZ]

Argue via PM, next snarky post will get the user banned from this thread.