Hi all,
I did just see this thread, and I want to provide a few updates.
1. I am still alive and well, not that anyone seemed overly concerned there
:D
2. My website is down because I accidentally kicked out the network cable
for my raspberry pi, and I didn't notice. I will be fixing this shortly.
3. I have been diligently working on Text Sweeper for the last week, and I
have some updates to share.
Updates coming soon.
1. I started managing the codebase through a Private git repository. I
will opt to just make this Public for posterity's sake when I release the
next updated version.
2. I have removed the AsciiPixels integration. While it was nifty, I
think it went against the spirit of the game, which was intended to be an
entirely text-based Minesweeper clone.
3. I have modified a significant amount of the codebase. I have
rewritten a large portion of the mine generation, and some of the other
common subroutines.
1. Mine generation algorithms used to be naive. I would pick a spot
to put the mine, check if it isn't within the initial 3x3 area
of the first
click, and check if it wasn't already a mine.
1. This has a theoretically infinite upper bound, as RND could
generate invalid spaces forever. This is noticeably slow when running
denser minefields
2. I replaced it with an algorithm that will always select a space
that is valid.
1. Accomplished by generating the array of all spaces
upfront.(done in ML for performance reasons) And then
removing the 4-9
invalid spaces around X,Y
2. After selecting a space, it's value will be set to -1 in the
initial array
3. Next, I use RND to generate a value(I%) between 0 and
256-SpacedAlreadySelected
4. Finally, I loop over the spaces in the array, and increment
the array index(I%) for each -1 in the array. This yields
a new I%, which
is the Nth non-negative position in the array. (done in ML
for performance)
3. This means that each loop in BASIC generates a valid position,
and the loop runs MN% number of times, where MN% is the
number of mines we
have to generate. Previously, it would run anywhere from MN%
to infinity.
2. Mine adjacency counts were done at the time of checking the cell.
I moved this to happen immediately after the generation of the
minefield. I
also have an ML routine that generates the upper and lower bounds for
checking a cell.
3. Using that same ML routine as above, to generate the bounds when
checking the mines.
1. So far there is about a 20-30% measured improvement on the mine
checking of the first move. (benchmarked using a 100 count minefield)
4. I replaced most of the GOTOs with FOR loops where applicable.
5. Refactored a lot of the code to just remove duplication where
unneeded.
6. The way I inserted ML into the program.
1. I dimensioned INT arrays for each subroutine.
2. I poked in my code from Data Statements.
3. I limited absolute addressing and jumps as much as possible.
1. In the case where I need to do JMP operations, I have BASIC
modify the ML addresses prior to execution.
4. I'm not an expert, but as I understand it, this should mean
that the ML code won't conflict with any other programs in
memory, as long
as you have the free space for BASIC to DIM the arrays. If
not, it will
fail safely.
4. Flagged mines must be unflagged before selecting them. Prevents
accidentally setting off a flagged mine.
5. Other features I want to add:
1. Selecting a space where the Number in the cell == Flags in
surrounding cells will open all adjacent cells. This is a common
feature in
other versions.
2. Additional controls for L/R/U/D. I developed this mostly using
VirtualT to test. The arrow keys kind of stink as the interface on an
actual M100.
3. Rewrite some additional pieces in ML if possible, to improve the
speed at which means are revealed. This part is slow and makes the game
less fun.
4. Add some instructions into the game itself.
After all this is complete, I will make the github public, which will
include the assembly code as well.
Please let me know your feedback on any of the above, and if you have any
suggestions. Please bear with me, I just taught myself assembly over the
weekend so it's been a bit of a trial by fire. :D
Best,
George
On Wed, Jul 6, 2022 at 7:17 PM Ken Pettit <petti...@gmail.com> wrote:
> Hi All,
>
> Sorry, didn't reply to this for quite some time ... the family caught
> Covid-19 last week and I was still recovering (I was taking care of
> everyone and then was the last to get it).
>
> I will look into my T200 AciiPixels implementation to see if I ever (or
> can still) get it to a stand-alone .CO file.
>
> Also, I will document the binary format so it is no longer "Top Secret" :)
>
> Ken
>
> On 6/30/22 10:33 PM, B 9 wrote:
>
> If you would, I'd greatly appreciate it as reverse-engineering it and
> porting it to the T200 is well beyond my abilities.
>
> Also, correct me if I'm wrong, but is the only documentation for the
> graphics format in the source code (e.g., pbm2ap.c)? The docs I found on
> club100 simply say, "TOP SECRET!" 😆
>
> --b9
>
> On Thu, Jun 30, 2022 at 12:59 PM Ken Pettit <petti...@gmail.com> wrote:
>
>> Hey b9,
>>
>> I would have to go back and check the T200 support. I know I had ASCPIX
>> working on T200 at one point because I had a few demos of some full-screen
>> images and even a screen mock-up of Mahjong tiles.
>>
>> Ken
>>
>> On 6/30/22 12:33 AM, B 9 wrote:
>>
>> Thank you, Tom and John! TSWEEP doesn't seem to work on my Tandy 200 when
>> ASCPIX.CO is loaded. I get a syntax error in line 16000 which is the
>> first call to ASCPIX that actually tries to show something: CALL A, 2,
>> VARPTR(F$)
>>
>> Ken Petit's member page at club100 has a download for ASCPIX.CO that
>> mentions the Model 100/102, but I don't see a separate version for the
>> Tandy 200. The documentation for ASCPIX
>> <http://www.club100.org/memfiles/index.php?action=view&filename=ap_doc.txt&directory=Ken%20Pettit/AsciiPixels&;>
>> says it works for both, but doesn't mention how.
>>
>> Perhaps I am using it wrong? There are no instructions in the TSWEEP
>> program, so I'm using the brief instructions Ken Petit
>> <https://www.mail-archive.com/m100@lists.bitchin100.com/msg03624.html>
>> posted back in 2017.
>>
>> CLEAR 256, 58000
>> LOADM "ASCPIX"
>> RUN "TSWEEP"
>>
>> —b9
>>
>>
>> On Sun, Jun 19, 2022 at 8:32 PM John R. Hogerhuis <jho...@pobox.com>
>> wrote:
>>
>>> Here's some files I have in my Google drive For tsweep
>>>
>>
>>
>
