Graph2fnt

[emkay]

@Tebe

 

What is Rasta Atari Juice mode?

I'd say it's another interesting idea. Using the CPU for racing the beam color changes and to leave PMg free , gives nice side effects.

[tebe]

 

I ran into an issue when modfying this image, and I did some reading. Here what probably is a stupid question:

 

The image (above) is in 5 color mode. On this picture, I enabled the feature Special -> Mode -> GED+ -> Disable Badlines. When I did this, COLPF2 (Color2, which was green) disappeared completely from the picture. My understanding is that this is using Konop's Mode, and we're changing the character set with every 8 vertical lines, but the video memory for the line itself... does it stay the same every time? Am I not able to switch between COLPF2 and COLPF3 because it doesn't also copy video memory (potentially ~40 different characters for each line to capture which ones are inverse), or is something else going on?

 

Thanks, all.

 

disable badlines = each row has same chars (ANTIC it load only first row into internal memory)

 

if you set invers at position X=5 ; Y=10 then invers is enabled on each Y position Y=<0..29> and X=5

 

 

Heaven/TQA, on 29 Jan 2018 - 06:40 AM, said:

@Tebe

 

What is Rasta Atari Juice mode?

 

GED-- (bitmap mode), possible additional 3 changes per line

 

or

 

GED+ (char mode), possible additional 4 changes per line (with disable badlines) and 5th color (with limitations)

 

 

for all this cases PMG are free

 

badlines.zip

bunny.zip

Edited January 29, 2018 by tebe

[pps]

The bunny.g2f loads fine into Graph2font, but creating the asm file does not work. There are to many changes per line given what you see when you press check as graph2font hints you to do.

[jmccorm]

 

disable badlines = each row has same chars (ANTIC it load only first row into internal memory)

if you set invers at position X=5 ; Y=10 then invers is enabled on each Y position Y=<0..29> and X=5

 

 

Understood. For now, I've stopped disabling badlines. I have two new issues with vertical scrollers:

 

I've included two G2F files for testing. I created a simple map with those two images and exported two vertically scrolling binaries (the .xex files were produced by Graph2Font, but with two different versions of the Graph2Font).

 

1. Temporary glitch in vertical scrolling. Both .XEX versions have a temporary glitch. Perhaps by coincidence, it is right when that same green area begins and ends in the FBI seal. I don't think there are any remaining rasters or PMGs that could be contributing to this. EDIT: This may be happening because I made a scrolling binary from two unrelated images. I think the massive color changes between the two images, all on one line, may be a contributing factor. It may have exceeded the limit on the number of changes in a scanline, without warning me?

 

2. Regression in 4.0.2.2? New vertical scrolling corruption. The testvert-4022.xex binary has a problem that the testvert-4013.xex does not. Perhaps related, the 4.0.2.2 binary file is a bit smaller. I first noticed this on a three-page vertical scroller that I was working on (it worked fine in 4.0.1.3 but corrupted under 4.0.2.2). I reproduced the problem, as seen, on this simple set of two images.

 

TEST FILES ATTACHED:

testvert-4013.xextestvert-4022.xexg2f-images.zip

Edited January 29, 2018 by jmccorm

[tebe]

The bunny.g2f loads fine into Graph2font, but creating the asm file does not work. There are to many changes per line given what you see when you press check as graph2font hints you to do.

bunny_OK.zip

[tebe]

 

Understood. For now, I've stopped disabling badlines. I have two new issues with vertical scrollers:

 

I've included two G2F files for testing. I created a simple map with those two images and exported two vertically scrolling binaries (the .xex files were produced by Graph2Font, but with two different versions of the Graph2Font).

 

1. Temporary glitch in vertical scrolling. Both .XEX versions have a temporary glitch. Perhaps by coincidence, it is right when that same green area begins and ends in the FBI seal. I don't think there are any remaining rasters or PMGs that could be contributing to this. EDIT: This may be happening because I made a scrolling binary from two unrelated images. I think the massive color changes between the two images, all on one line, may be a contributing factor. It may have exceeded the limit on the number of changes in a scanline, without warning me?

 

2. Regression in 4.0.2.2? New vertical scrolling corruption. The testvert-4022.xex binary has a problem that the testvert-4013.xex does not. Perhaps related, the 4.0.2.2 binary file is a bit smaller. I first noticed this on a three-page vertical scroller that I was working on (it worked fine in 4.0.1.3 but corrupted under 4.0.2.2). I reproduced the problem, as seen, on this simple set of two images.

 

TEST FILES ATTACHED:

testvert-4013.xextestvert-4022.xexg2f-images.zip

 

1. temporary glitch: DLI program is too slow, too many changes in line (change limit /Ctrl+E/ does not matter)

[ilmenit]

Really nice program Tebe! Without the need to mix PMG and playfield colors there is no need to perform complex optimizations like in Rasta. Such setting, where PMGs are free to use, has many more use-cases (games, demos) than just static pictures of Rasta Converter. In many cases the output without PMG is still good and lack of this layer allows way easier editing/post-processing in G2F.

[tebe]

 

Understood. For now, I've stopped disabling badlines. I have two new issues with vertical scrollers:

 

I've included two G2F files for testing. I created a simple map with those two images and exported two vertically scrolling binaries (the .xex files were produced by Graph2Font, but with two different versions of the Graph2Font).

 

1. Temporary glitch in vertical scrolling. Both .XEX versions have a temporary glitch. Perhaps by coincidence, it is right when that same green area begins and ends in the FBI seal. I don't think there are any remaining rasters or PMGs that could be contributing to this. EDIT: This may be happening because I made a scrolling binary from two unrelated images. I think the massive color changes between the two images, all on one line, may be a contributing factor. It may have exceeded the limit on the number of changes in a scanline, without warning me?

 

2. Regression in 4.0.2.2? New vertical scrolling corruption. The testvert-4022.xex binary has a problem that the testvert-4013.xex does not. Perhaps related, the 4.0.2.2 binary file is a bit smaller. I first noticed this on a three-page vertical scroller that I was working on (it worked fine in 4.0.1.3 but corrupted under 4.0.2.2). I reproduced the problem, as seen, on this simple set of two images.

 

TEST FILES ATTACHED:

testvert-4013.xextestvert-4022.xexg2f-images.zip

 

create FIRST VSC file and remove warnings (CTRL+E -> Check)

 

if you append any g2f file then creates new complex color issue

 

only VSC file showing it

vert.zip

[jmccorm]

create FIRST VSC file and remove warnings (CTRL+E -> Check)

if you append any g2f file then creates new complex color issue

only VSC file showing it

 

Thank you for showing how a .VSC can show any line warnings and errors between images in a vertical scrolling binary.

After you fixed that line error which Graph2Font reported, we still have those same two problems.

 

The two problems that we still see in a vertically scrolling .XEX:

 

After the line warning was fixed, the two problems still exist.

 

The problems are also seen in your vert.zip file:

vert/Atari/vert.xex

 

Here are the two problems that we can see in your vert.xex:

 

Problem #1 - A one-line glitch (FBI logo, top of green area, glitch is temporary)

• It is also the line were COLOR2 is used for the first time (in this second image of 5 colors).
• It seems to correct itself while the first image is no longer on-screen.

Problem #2 - Major pixel corruption (FBI logo, lower half of logo)

• Was not in version 4.0.1.3.
• It is a new problem in version 4.0.2.2.
• Easy to re-create. Make a new vertically scrolling binary from two or more images.
• Problem is worse in a vertical scrolling binary that is made from three or four images.
• Sometimes the corrupted area contains pixels that change or move horizontally.

I am reporting two different problems that we happen to see in the same output.

The two problems look like they are independent of each other.

 

Screenshot:

 

Animated GIF:

 

Video (poor 10fps quality):

vert-corrupt.mp4

 

I hope this new message is more clear and is helpful. Thank you for your support.

Edited January 31, 2018 by jmccorm

[tebe]

new fixed G2F 4.0.2.3 http://g2f.atari8.info

 

 

vert_OK.zip

[jmccorm]

Hi, tebe! Thank you so much for working on this!

 

No more Problem #2. Awesome!

 

A problem seen in your vert_OK.zip -> girl -> Atari -> girl.xex

Many YELLOW pixels change (appear / disappear) during vscroll.

Seen with Altirra [NTSC] and 130XE [NTSC].

Not seen with Altirra [PAL].

May be related to problem #1?

I will try to take snapshots and write more later.

[tebe]

PAL is better then NTSC

[_The Doctor__]

But there is no reason to make pal ntsc incompatibilities and that's becoming a real pita. oh look here's a new calculator it does 2+2 but it's not going to work on ntsc yaddah yaddah yaddah, complaints start, someone comes along, changes a counter, removes half a line, or trims blank lines (empty space). and voila the 'impossible' happens--- you get 4!

 

Some of the 'coded all the way to the end' 'no space' stuff can be spread out moving the offending code forwards or backwards depending on it's critical nature, and then spread out to additional line. It's a complete restructure not unlike re organizing for a cartridge, racing the beam style. It's alot of work, so of course you'll get the it's all impossible gotta lose features talk. It still comes down to how many clocks per time interval. This has been calculated and proven a number of times. Yet every 8 or so years it gets trotted out again. I don't think there are any NTSC coders left with the time to do completely re-coded versions with no real help from the creators. It's like the old days where once it's made there is no comments within the code and the people who made it don't remember whats what because they squeezed whatever they could in there and have no outline of what each chunk does and how they join together. I'm guilty, I suspect many others are too

[emkay]

But there is no reason to make pal ntsc incompatibilities and that's becoming a real pita. oh look here's a new calculator it does 2+2 but it's not going to work on ntsc yaddah yaddah yaddah, complaints start, someone comes along, changes a counter, removes half a line, or trims blank lines (empty space). and voila the 'impossible' happens--- you get 4!

Seems, you don't see the real problem.

 

Let's have a look at the game Salmon Run.

It is optimized for NTSC. Which means, the scrolling is adjusted to 60 FPS, dropping a small amount of free cycles. Some parts run free on CPU, to use all what a 60Hz machine can offer. So the "free" running stuff is rather slow. That means, the salmon can swim upwards the river and there is the Bear. It moves simultaneously to the 60Hz scrolling speed. Everything is fine. The Salmon has a real change.

Now play the game on a PAL system. The River floats now 10 fps slower. The Computer has a lot of free cycles left.

Now the bear runs directly towards the salmon. The game gets unplayable at a dedicated point.

 

Rescue on Fractalus runs slower due to the vertical sync, on PAL computers. Making approx. 20% of the system unused.

Rockford in Boulder Dash always tend to run out of the screenrange on a PAL system. As it is not disturbing the Gameplay, it looks like a funny easter egg.

 

 

Heck, NTSC Computers have color in hires. Where is the fix for PAL computers ?

Similar with music replay. 60Hz instead of 50Hz allows to have control over 1/1 , 1/2 , and even clean 1/4 speed notes. To do similar on PAL, you have to replay at double VBI speed. Double speed music in NTSC runs into CPU issues again.

 

If you want to have PAL system goodies, you have to do the games for PAL . The whole software has to be adjusted to the screen syncing.

 

If you do always compromises to fit the games to both systems, you always use only 60% of the available resources.

[_The Doctor__]

exactly and the other way around - games like Dropzone play super fast, or timers run out like in Elektraglide, or music plays super fast or all three... you can certainly fit more in between or after. You would have to adjust it ALL, but we choose simple fixes to do it quick and dirty, adjust some counters or slow a routine down throwing cycles away, who wants to change duration on all that stuff. As long as it works no one cares Get into a tightly packed code crunch situation and now we've got no choice but to re code, you can move it up pulling it together and make up some speed, or push it down and apart and it slows down, it's a see-saw. Crawling through it moving everything around for timing. Overly simplified, a generalization to be sure. but it is what it is.

Edited February 3, 2018 by _The Doctor__

[tebe]

PAL is more modern than NTSC

 

https://www.diffen.com/difference/NTSC_vs_PAL

[_The Doctor__]

lol, secam looks awefully big on that map...

NTSC can decode PAL, Pal can't decode NTSC... I remember a VCR with dual tuners like that.

anyway it is what it is, I prefer higher refresh rates... for certain on x86 machine 72 or higher displays please and television 120 panel or better.. though they do play all kinds 'motion rate' games.... 240 or higher for that as you can see the processed image difference. Oled or plasma.... anything else is disgusting

For crt's 30slow phosphor/60/72/78 all other are a flickering stab to the eye sockets, and give fatigue or headache. Just can't handle the pagebook flipping nature of it.... 25/50 is a pulse fest though 50 on a slow phospher is ok, it takes many days of trying to acclimate to it....before I can watch a show... it's just what your brain and eyes are train to I guess... same way some people can see an optical illusion for what it is while others are fooled.

Edited February 3, 2018 by _The Doctor__

[+MrFish]

Having a problem with the latest version and my Monopoly board when saving out an XEX.

 

It was saving out fine with v4.0.1.3

 

 

 

But wreaking havoc on the P/M's with v4.0.2.3

(worse in "Optimized" mode, where PM's are jumping all over; stable here using "Standard" mode)

 

 

 

There are no errors when doing a "check".

 

I tested out on real hardware and the results were the same.

 

I'll send the Graph2Font file to you in PM Tebe...

Edited February 4, 2018 by MrFish

[tebe]

MrFish, enable PM graphics

 

Special -> Limitations

Edited February 4, 2018 by tebe

[_The Doctor__]

I hope I'm ok suggesting..

Special

Chars Optimising

unless your spelling it the other way on purpose

[tebe]

Chars optimizng is optional, ENABLE PMG DMA is important (you had it turned off)

 

PMG = Player/Missile Graphics

 

 

my suggestion

 

Edited February 4, 2018 by tebe

[+MrFish]

Odd, I hadn't done anything to the original file, just loaded it in Graph2Font and saved the XEX to view. In fact I never do anything with any of those settings.

 

No matter, though; at least I know where to look if anything happens in the future.

 

Thanks Tebe.

[tebe]

G2F is growing up and add some new features, like GED CPU register, Enable PMG DMA, but default sets all this features to FALSE (value 0)

[jmccorm]

Having a problem with the latest version and my Monopoly board when saving out an XEX.

Are you using this as the basis for an actual monopoly game? Because those graphics are outstanding!

[+MrFish]

Alright, thanks for the warning, but it's odd that none of my other older files had these options turned off when loading them in v2.0.2.3.