News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Yagol4CPC alpha release

Started by opqa, 17:16, 25 October 14

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

opqa


Edit: Sources added to the attachments

Hi all, I attach the very first preliminary alpha version of Yagol4CPC (Yet another Game of Life for CPC). As you might guess is just another attempt to implement the infamous Conway's Game of Life in the CPC, it just started as a personal challenge to improve the speed over litwr's Xlife-8 Commodore/+4 version, and I managed to find an algorithm that turned out to be very fast for small and medium sized patterns (in terms of active population).
 
This is the first version that includes the basic functionality and interactivity every Game of Life should have. There is still a lot of room for improvement, it is not intended to be a final release, but I can't assure whether I will continue working on it or not.

ABOUT THE PROGRAM

This version only works in CPC6128 (sorry), as it makes use of extended memory banks. The core algorithm can run in just 64KB's, but I wanted to show an information panel while the evolution was running, and for that I needed at least another bank for the panel video memory. A stripped down version without the panel could be adapted to the 464 and 664, but this is not in my priority list right now.

This information panel lies in a different RAM bank than the Game area thanks to the vertical rupture technique. When the panel is being shown, it overlaps with the Game area hiding 2 chars. But thanks to the vertical rupture technique you can scroll line by line (pixel perfect) the game area. Also at any moment, you can hide the information panel (deactivating the rupture), and see the whole Game area, it is also possible to scroll the Game area in this case (it uses a toroidal topology so the top and bottom borders are "connected"), but only 8 lines at a time.

There is another particularity in the video system of this program, it reduces the frame size vertically one scanline (from 312 to 311), thereby incrementing the framerate (from about 50.08Hz to about 50.20Hz). If you have your CPC connected to a monitor or a television it might not accept this slightly increased frecuency. If it's your case I would like to know here. This frequency change is intentional because it simplifies the rupture, but it could be avoided.
Now,

HOW IT WORKS

When the program starts it asks for a file to load that should contain the initial pattern. There are a few in the disk (files with .PAT extension), but in case you want to create your own, these are just CPC screens with the following "specs":

- Mode 0
- Linear layout
- 128 x 256 pixels (the grid size the program supports)
- Dead cells should have ink 0 and live cells ink 10 (decimal).

This format is far from optimal and not definitive, each pattern takes 17KB's regardless of its actual size. But there is enough room in a disk for some of them.
Once the pattern is loaded the program starts showing it, from this moment on the following controls are available:

SPACE - Start/Pause evolution
F - Show/Hide information panel
C - Toggle colour mode (from 4 possible combinations)
D - Enable double buffered mode, this mode also forces monochrome colour mode, this is an algorithm limitation.
VERTICAL ARROWS - Scroll the game area
1-9 - Advance N generations and pause
RIGHT ARROW - Keep advancing generations (at a limited display rate) while pressed

And that's all for the moment, feedback welcome.

TFM

#1
Thanks for using 128 KB!  :)

Actually that's probably the most quick version I ever saw on the CPC!

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

MacDeath

#2
QuoteThis version only works in CPC6128 (sorry)
Many Amstradists (well only me in fact) have a poor opinion on 64K only machines...

No more a problem as it would bump the sales for X-MEM cards...

Only a loosy 64k config ? just call TotO.

Cent Pour Cent - CPC News

Not sure if this is possible but you may also get a version to use the 128k RAM +444k RAMdisk offered by a proper +512K RAM card if you want, as those cards already sold hundred units..


Vertical 256 pixels is considered "safe display zone" but CPC can actually go a bit more on a lot of screens.


I fail to understand how it goes from 50hz to 50.20 hz with one less line...
Not sure CPC is supposed to work that way : the video circuit stays at its 50hz (or 25Hz if you want) and the pixels displayed are constant in size and height...
You just tell the video to display less lines and it just adjusts the border. but on CPC you don't magnify the pixels to fill a fixed surface on screen, just that the pxiels ratio changes depending on Video mode used, not screen resolution set.

When a CPC displays a Spectrum-like 256x192... you just get a freaking huge border, not those 256x192 filling the same space on screen as the 320x200 and so on.

I understand that this software uses vertical scrolling and hereby manages more lines than displayed... still fail to see how it can impact the CRTC-Gate array video circuit...

litwr

I dare to think that even Commodore Amiga 500 or Atari ST have no such fast GoL implementation.  :D Yagol's algorithm 2-3 faster than Xlife-8's in many cases.  However it is a bit sad that it doesn't allow to use directly the big pattern library of Xlife-8.  :( This makes the play more difficult.
I also missed the sum of cells and the rules indication.  I hope they will be added.  IMHO to show the dead cells should be the last options with C-command.  It is also possible to add the fifth color mode which shows the only changed cells like at Xlife-32/64.
The speed indicator is very impressive.  :)

Quote from: opqa on 17:16, 25 October 14
litwr's Xlife-8 for the Commodore/+4
It is not true.  ;) Xlife-8 is multiplatform. One of its major port is Amstrad CPC. BTW the new edition of Xlife-8 for CPC6128 is faster for all screen on modes than the new edition for Commodore +4.  The better usage of z80 codes gives 2.4:1 (or 3:1 if we will count the wait states) to the 6502:z80 speed ratio. So for the Xlife-8 calculations Commodore 64 is equivalent to Amstrad CPC at 2.8 MHz, Commodore+4 - 3.4 MHz, Commodore+4 with blank screen - 5.1 MHz.
Do you plan to publish Yagol's sources?

Gryzor

Heh, I'm displaying this on my TV right now - the colours, man! :D

Really nice, and I love the smooth vertical scroll...

opqa

Quote from: litwr on 17:32, 27 October 14
It is not true.  ;) Xlife-8 is multiplatform. One of its major port is Amstrad CPC.

Yes, I did not mean that, I just meant that my goal was to beat the Commodore+4 version, this is, that for me was Commodore vs Amstrad thing, and this influenced the way I chose the algorithm. You wrote somewhere that the CPC version was slower due to the slower video system (weird layout and a lot of RAM to write to). I believe this, it is one of the defects of the CPC design, a lot of Video RAM to manage but a rather slow processor to do it without extra hardware help.

So to avoid this I searched for an algorithm which could use the same video RAM to store the grid information and calculate directly over it rather than having a "calculation" process and a separated "printing" process. Of course this loses a lot of flexibility, it is not possible to zoom in or use different graphic modes, the displayed aspect ratio is the one of mode 0 (2:1)... but helps to overcome the big RAM size issue. The weird layout issue is still there but one has to deal with it, there's no other chance.

Quote from: litwr on 17:32, 27 October 14However it is a bit sad that it doesn't allow to use directly the big pattern library of Xlife-8. :( This makes the play more difficult.

I'm still thinking about which will be the "main" load format for the program. I could adopt Xlife-8 one but I'm also tempted to add support to read directly the RLE format for life patterns which is widely used over the internet, of course supporting the two of them would be great but I have to prioritize... In order to save the maximum possible disk space it would also be great to add the possibility to store several patterns over the same file, so when a user selects a multi-pattern file the program would scan it and offert the option to select which one to open. This would save a lot of disk space because with the DATA and SYSTEM formats each file takes a minimum of 512 bytes of disk space (or was it 1K?) no matter how much it really occupies the data inside.

Quote from: litwr on 17:32, 27 October 14
I also missed the sum of cells and the rules indication.  I hope they will be added. 

The (total) sum of live cells is not something that can easily be added, I would have to insert some extra code in the core of the algorithm to keep track of this count thereby slowing it down a bit. I'm not sure whether it is worth to do so. If this is an important parameter it could be added an option to count them while in paused state.
About the rules, at this moment they are fixed to these of the classical Conway game, I would like to add support to change them in the future but this is not among my first priorities.

Quote from: litwr on 17:32, 27 October 14
IMHO to show the dead cells should be the last options with C-command.  It is also possible to add the fifth color mode which shows the only changed cells like at Xlife-32/64.

Take note, this should be rather easy to implement.

Quote from: litwr on 17:32, 27 October 14
Do you plan to publish Yagol's sources?


Yes, I will publish them in a moment in the first post of the thread.

opqa

#6

Sorry, missed that question from MacDeath
Quote from: MacDeath on 13:54, 27 October 14I fail to understand how it goes from 50hz to 50.20 hz with one less line...Not sure CPC is supposed to work that way : the video circuit stays at its 50hz (or 25Hz if you want) and the pixels displayed are constant in size and height...You just tell the video to display less lines and it just adjusts the border. but on CPC you don't magnify the pixels to fill a fixed surface on screen, just that the pxiels ratio changes depending on Video mode used, not screen resolution set.When a CPC displays a Spectrum-like 256x192... you just get a freaking huge border, not those 256x192 filling the same space on screen as the 320x200 and so on.I understand that this software uses vertical scrolling and hereby manages more lines than displayed... still fail to see how it can impact the CRTC-Gate array video circuit...

In this part I was talking about the total frame size, including the displayed area, the border, and the invisible lines. This size is controlled by registers 4 (Vertical Total) and 5 (Vertical adjust) of the CRTC.

When a game changes the vertical window size it normally only touches register 6 (Vertical displayed) and 7 (Vertical sync position) to re-center, leaving the total frame size invariant.

In an Amstrad CPC configured for the PAL standard a progressive (non-interlaced) frame has a total of 312 scanlines, of which only 288 are displayed.

As the pixel clock is fixed at 1us per mode 1 character (2 bytes when displaying from the video memory), and as long as the "horizontal total" config is left untouched (64 mode 1 characters), the "vertical total" config will impact the total duration of the frame, and hence the frequency or frame-rate. The maths are simple:

312 scanlines/frame x 64 (horizontal characters)/scanline x 1 us/(horizontal character) = 19968 us/frame

which gives us a frequency of:

1 frame/0.019968 s = 50.08 Hz (frames/s) (I wrote this data by heart, edited now)

If you reduce to 311 scanlines you'll get ~50.20 Hz.

To complement, you may like to know that in the CPC firmware there is provision to increase this frequency to 60 Hz, which suits the NTCS standard. There is one bridge in the board for this setting, the firmware detects its state when it boots and re-programs the CRTC to match the selected frequency (either 50(.08)Hz or 60(.someting)Hz).
In real practice I believe this wasn't used as long as the computer came with its own monitor, but I'm not sure, maybe in the USA market they came configured for 60Hz.

MacDeath

thx for the lesson. :)

litwr

#8
Quote from: opqa on 22:42, 27 October 14
it is one of the defects of the CPC design, a lot of Video RAM to manage but a rather slow processor to do it without extra hardware help.
This problem is common: Raspberry Pi, for example, has CPU slower than GPU.  The most successive Amstrad PCW has even slower video than CPC. However you turned this disadvantage into the limited advantage.  :) I write "limited" because all hardware based technologies are not so flexible as software.

Quote from: opqa on 22:42, 27 October 14
I'm still thinking about which will be the "main" load format for the program. I could adopt Xlife-8 one but I'm also tempted to add support to read directly the RLE format for life patterns which is widely used over the internet, of course supporting the two of them would be great but I have to prioritize... In order to save the maximum possible disk space it would also be great to add the possibility to store several patterns over the same file, so when a user selects a multi-pattern file the program would scan it and offert the option to select which one to open. This would save a lot of disk space because with the DATA and SYSTEM formats each file takes a minimum of 512 bytes of disk space (or was it 1K?) no matter how much it really occupies the data inside.
A lot of Xlife-8 patterns (about 50%) are just the conversions from RLE. My point is to provide a converter from the common formats (RLE, L, ...) to an 8 bit format. It is provided - its name is lifeconv. It is written in C but requires 32/64 bit platform. RLE is a textual format so it requires a parser. I may count the next disadvantages of RLE for the 8-bit platform:
1) it may have variations difficult to parse;
2) the file size may be bigger up to 2-3 times than the binary equivalent;
3) it will be not easy to realize to show the comments directly from RLE;
4) there are other popular formats (mcl, cells, lif, mc, ...);
5) RLE doesn't allow to make a file container with the multiple patterns, Xlife's native format (made by famous Eric S. Raymond) allows to do such things but IMHO it is too difficult to parse at 8-bit system;
6) it doesn't provide the bounding box size for the pattern.
As I know all standard Amstrad's disk formats use 1KB clusters and have only 64 directory entries.  Old Commodore 1541 drives (1982) are much better here: 256 bytes per cluster and 144 directory entries.  The newer 1581 has even 292 directory entries. Maybe you should design a packer, a program which may pack several XLife-8 or other formats patterns into one and make YAGOL capable to handle packed and single files. So we will see the united directory listing without the packed files themselves.
Quote from: opqa on 22:42, 27 October 14
The (total) sum of live cells is not something that can easily be added, I would have to insert some extra code in the core of the algorithm to keep track of this count thereby slowing it down a bit. I'm not sure whether it is worth to do so. If this is an important parameter it could be added an option to count them while in paused state.
Xlife-32/64 has c-command to toggle the cell count.  ;) IMHO The total absence of possibility to count cells is a big disadvantage which makes difficult to check patterns, etc.
Quote from: opqa on 22:42, 27 October 14
About the rules, at this moment they are fixed to these of the classical Conway game, I would like to add support to change them in the future but this is not among my first priorities.
Where is the problem? Yagol uses table defined by rules, it only needs the 256 bytes table generator.  This table format is the same (?) as in updated Xlife-8. I attached this table for the Conway's rules. If it is the same I may attach the subroutine-generator for it. The different rules - the different life and the different games.  :D

TFM

Quote from: opqa on 10:18, 28 October 14
To complement, you may like to know that in the CPC firmware there is provision to increase this frequency to 60 Hz, which suits the NTCS standard. There is one bridge in the board for this setting, the firmware detects its state when it boots and re-programs the CRTC to match the selected frequency (either 50(.08)Hz or 60(.someting)Hz).
In real practice I believe this wasn't used as long as the computer came with its own monitor, but I'm not sure, maybe in the USA market they came configured for 60Hz.


I can confirm this. I brought my 6128 to the USA and used an original CTM644 (made for the US market). The CPC has a switch (LK 4) to select 50 or 60 Hz. And both do run well with the US CTM644 (see my thread about it). Sadly after six years of searching for a US CTM644 it worked only six weeks then if went dead. So I can't make further tests.

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

CraigsBar

Quote from: TFM on 18:42, 29 October 14

I can confirm this. I brought my 6128 to the USA and used an original CTM644 (made for the US market). The CPC has a switch (LK 4) to select 50 or 60 Hz. And both do run well with the US CTM644 (see my thread about it). Sadly after six years of searching for a US CTM644 it worked only six weeks then if went dead. So I can't make further tests.
Hmmm, I wonder if the plus machines have such a jumper, and what the speed increases are like on a PAL 60 Capable SCART TV woudl be like?
IRC:  #Retro4All on Freenode

TFM

No speed increase, the CPU runs still at 4 MHz. In contrast, when using 60 Hz the CPU has more work to do  ;)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

CraigsBar

Quote from: TFM on 21:42, 29 October 14
No speed increase, the CPU runs still at 4 MHz. In contrast, when using 60 Hz the CPU has more work to do  ;)
surely more frames per second.... Smoother, less flicker.... No?
IRC:  #Retro4All on Freenode

TFM

Well, if a game uses up let's say 90% of the cpu time of a frame and runs at 50 fps and you switch to 60 Hz it will not be able to do everything in a frame, so frame rate will effectively to 30 fps.

That's  :o , but it happens.

Of course it depends on the single game etc.

In case of demos, you can assume that most of them would become problems.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

opqa

#14
Quote from: litwr on 18:36, 29 October 14
Where is the problem? Yagol uses table defined by rules, it only needs the 256 bytes table generator.  This table format is the same (?) as in updated Xlife-8. I attached this table for the Conway's rules. If it is the same I may attach the subroutine-generator for it. The different rules - the different life and the different games.  :D
Of course it can be done, the problem actually is just time, due to some recent changes in my life my CPC development time has dropped near to zero. And I had some there are so many other features I would like to add first. You may have noticed that the first line of the panel is left blank. My plan was to add a DOS application style menu with options and keys linked to that options, you know, like, F1 - Load pattern, F2 - Edit Pattern, F3 - Options, and so on... Too many ideas and too little time to materialize them.
Anyway anyone is welcome to make any additions and publish them. I don't claim any copyright neither any ownership notes for this work.

Quote from: litwr on 18:36, 29 October 14My point is to provide a converter from the common formats (RLE, L, ...) to an 8 bit format. It is provided - its name is lifeconv.
I know, this is a good point of your format, but having to (necessarily) use a command-line converter can also be a barrier. I would be great if lifeconv could be compiled also for the CPC and used from there.
About the disadvantages of the RLE format, I don't share some of them, namely...

Quote2) the file size may be bigger up to 2-3 times than the binary equivalent;
I don't see it, it is somewhat compressed (RLE is a basic kind of compression), and aside from some little overhead it's storage density could be at worst around 1 byte per live cell (normally it should be quite less due to the RLE compression). IIRC xlife-8 format needs two bytes per cell and it doesn't implement any compression.
Quote5) RLE doesn't allow to make a file container with the multiple patterns,
As it is just plain text my plan was to simply concatenate files, which can be done from any command line or text editor. RLE has rather defined text separators to mark when a pattern starts and it has even some provision to assign it a name, so I believe that it could be done, maybe not easy, but feasible.
Quote6) it doesn't provide the bounding box size for the pattern.
I believe that it does, at the beginning in the form "x=10,y=15". Spacing can vary but it's easy to instruct the parser to just ignore spaces.
But anyhow back to the beginning, at this moment I have no time to add any more features, I shouldn't even be writing this, so feel free to add support for xlife-8 format if you want, it shouldn't be hard. The file "loadpattern.asm" first loads the file from the disc to the &4000- memory area, then there is small routine that copy the loaded image into the video region &c000 reordering the lines (the images in the disc have a linear layout). Just replace this routine for a xlife-8 parser that "paints" the live cells in the memory area with ink 10 and you're done.

opqa

Quote from: TFM on 18:42, 29 October 14
I can confirm this. I brought my 6128 to the USA and used an original CTM644 (made for the US market). The CPC has a switch (LK 4) to select 50 or 60 Hz. And both do run well with the US CTM644 (see my thread about it). Sadly after six years of searching for a US CTM644 it worked only six weeks then if went dead. So I can't make further tests.


Shouldn't a regular CTM664 support 60Hz just by adjusting it's VHOLD pot. at the back? I thought it could.

TFM

Quote from: opqa on 14:21, 30 October 14

Shouldn't a regular CTM664 support 60Hz just by adjusting it's VHOLD pot. at the back? I thought it could.


Right. It does. And the same way you can switch between 50 and 60 Hz for the US CTM.  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

litwr

#17
Quote from: opqa on 14:18, 30 October 14
my CPC development time has dropped near to zero
:( I hope that your project will survive the changes.  I checked your sources and found that Xlife-8's and Yagol's tables are a bit different but Yagol already has the procedure to generate any required table.  So the only problem is a friendly way to setup rules, is not it?

Quote from: opqa on 14:18, 30 October 14
I know, this is a good point of your format, but having to (necessarily) use a command-line converter can also be a barrier. I would be great if lifeconv could be compiled also for the CPC and used from there.
The universal converter for ALL formats at CPC?!  :o IMHO It is impossible - this will require the policy  :P and this will force to select the favorites.

Quote from: opqa on 14:18, 30 October 14
I don't see it, it is somewhat compressed (RLE is a basic kind of compression), and aside from some little overhead it's storage density could be at worst around 1 byte per live cell (normally it should be quite less due to the RLE compression). IIRC xlife-8 format needs two bytes per cell and it doesn't implement any compression.
The theory requires practice to check with.  ;) I checked dozen of randomly selected RLE patterns and converted them to Xlife-8 formats.  Then I dropped all comments from RLE and compared sizes.  I didn't skipped a line with the rules information. The size of RLE-file is usually at least 2 times bigger.  ;) If we will use the "raw" RLE then RLE-file will be usually 3 times bigger.
Quote from: opqa on 14:18, 30 October 14
As it is just plain text my plan was to simply concatenate files, which can be done from any command line or text editor. RLE has rather defined text separators to mark when a pattern starts and it has even some provision to assign it a name, so I believe that it could be done, maybe not easy, but feasible.
Yes, you describe some packer... *EDIT* I hope you find time to see at Xlife structured format too - see Xlife-32/64 manpage: the key feature is #I command.
Quote from: opqa on 14:18, 30 October 14
I believe that it does, at the beginning in the form "x=10,y=15".
Agreed, I was a bit  misled by information at the Golly help system: "The dimension data is ignored when Golly loads a pattern, so it need not be accurate, but it is not ignored when Golly pastes a pattern; it is used as the boundary of what to paste, so it may be larger or smaller than the smallest rectangle enclosing all live cells. " BTW Lifeconv checks and sets the smallest rectangle.
Quote from: opqa on 14:18, 30 October 14
But anyhow back to the beginning, at this moment I have no time to add any more features, I shouldn't even be writing this, so feel free to add support for xlife-8 format if you want, it shouldn't be hard. The file "loadpattern.asm" first loads the file from the disc to the &4000- memory area, then there is small routine that copy the loaded image into the video region &c000 reordering the lines (the images in the disc have a linear layout). Just replace this routine for a xlife-8 parser that "paints" the live cells in the memory area with ink 10 and you're done.
Thank you for this information.  However it is all theoretical matters... Xlife-8 is going to run at the other platforms, e.g., even PDP-11 clone.  ;) BTW I will be happy if the new version of Yagol will be released. RLE is also very well  :)  but it may also have different EOL markers.

litwr

Quote from: opqa on 14:18, 30 October 14
Just replace this routine for a xlife-8 parser
The binary format doesn't require parser, just loader.  ;)
BTW if Yagol will be stopped then the current Xlife for Commodore  ;D  will be the fastest complete GoL application.  :o

opqa

Quote from: litwr on 15:33, 31 October 14
The binary format doesn't require parser, just loader.  ;) 
Well, with "parser" I mean a routine that reads the x,y positions from the binary file, translate them to screen addresses, and "paint" points with ink 10, maybe it is not technically a parser, but something similar.

Quote from: litwr on 15:33, 31 October 14BTW if Yagol will be stopped then the current Xlife for Commodore  ;D  will be the fastest complete GoL application.  :o

I'm not sure what you mean with this, Is it that you have managed to make the current Commodore version faster than Yagol?

If that's the case then it is going to be faster no matter I continue developing or not. Right now Yagol is as fast as it can be, I see no way to improve in a significant way the core algorithm's speed. In case I continue developing it will be for adding features, but speed is going to stay like it is right now.

Anyhow, you know that Yagol is not the fastest implementation in absolute terms. It's speed is highly dependent on the ACP completion, for ACP < ~20% it performs quite well, the lesser the better. But for higher ACP completion speed begins to suck. An ideal implementation would automatically switch the core algorithm on the fly depending on this or other parameters, but this would require a lot of extra work and code.

TFM

Yes, please keep the good work going!  :) :) :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

litwr

Quote from: opqa on 14:33, 01 November 14
I'm not sure what you mean with this, Is it that you have managed to make the current Commodore version faster than Yagol?
I mean that the current state of Yagol is the demo level only.  It is impossible to do full check with it.  No pattern loader for the common formats or the converter, no sum of cells calculation, no rules support, ... So it requires one or two steps that make it the true application. So technically Xlife-8 for Commodore is still the fastest GoL application.  :P Yagol  :-* looks  like a very fast demo program only.   :D

opqa

#22
Oh, this, well, it's ok, I never intended to compete with xlife-8 in terms of functionality. It's multi-8bit-platform, it has a lot of integrated functionality, including editing, it is really impressive and has a lot of work behind, my first attempt was trying to modify the Amstrad version to make it faster, but when I took a look at the source code I discarded this idea, given the size of the project I thought it would be easier to start from zero.
Probably about in one month I will have some time again, I might add the xlife-8 pattern format support by then, but I can't promise anything right now.

Meanwhile there is no conversion program, but there are ways to create CPC screens in the needed format with any desired pattern, what I do is to use any x86 Life program to build it, then I take a screenshot with aspect ratio 1:1, paste the screenshot in an image editing program, convert it to a monochrome 128x256 picture, and last of all I open the ConvImgCPC utility to create a CPC screenshot with linear layout, in fact, Yagol uses linear layout because this utility doesn't do it right if one try to create the screen directly with CPC layout. I attach a screenshot of the settings I use to create the screen which can be transferred to disk and loaded directly by Yagol.

TFM

Quote from: litwr on 20:27, 01 November 14
I mean that the current state of Yagol is the demo level only.  It is impossible to do full check with it.  No pattern loader for the common formats or the converter, no sum of cells calculation, no rules support, ... So it requires one or two steps that make it the true application. So technically Xlife-8 for Commodore is still the fastest GoL application.  :P Yagol  :-* looks  like a very fast demo program only.   :D


Oh, oh, oh....  :o  don't you overdo it a bit here?

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

litwr

Quote from: opqa on 22:37, 01 November 14
Probably about in one month I will have some time again.
Good news :)
Quote from: opqa on 22:37, 01 November 14Meanwhile there is no conversion program, but there are ways
Thank you but they are a bit too complicated and multistepped.  Where will somebody take time to make all these MANUAL steps (IMHO it will take up to 5 min for one pattern conversion)? BTW Golly supports GIF/BMP-images to load as patterns.  Eric S. Raymond wanted to make the same things to Xlife even at 90s but the popularity caused the absence of time...
I have a question.  My knowledge of Amstrad CPC hardware is not too good.  :( So it is very curious for me about double screen buffer at Yagol.  As I know CPC always uses C000-FFFF from the 1st 64KB as video RAM.  So is it possible to have the several video RAM pages? Thanks in advance.
Quote from: TFM on 03:56, 02 November 14
don't you overdo it a bit here?
What is your point about the current state of Yagol?

Powered by SMFPacks Menu Editor Mod