Jump to content
IGNORED

Nice looking playfields?


MausBoy

Recommended Posts

I can't get:

const pfres=32

to work, it makes the screen roll and the score flicker in the middle of the screen. Yeah, I'm using 16kSC. In fact, nothing above 24 works for me.

 

So I'd designed a ton of fullscreen graphics in 32x32 and they are useless now, but I learned to deal with 32x24, except for one big problem; pfheight and pfcolor tables only seem to read the first 12 values. I've looked through the asm includes, and generated asm files, and I can't figure out how to fix this. Any ideas?

 

Also, scrolling in 1.0 sure is an awful mess. The score shakes, the colors roll, bleh. I'm running into bugs like crazy, I might just wait out a 1.1 release...

 

edit; I don't want to come off like I don't appreciate the huge amounts of work and effort that went into this release. It's definately still something I enjoy.

Edited by MausBoy
Link to comment
Share on other sites

I can't get:

const pfres=32

to work, it makes the screen roll and the score flicker in the middle of the screen. Yeah, I'm using 16kSC. In fact, nothing above 24 works for me.

 

So I'd designed a ton of fullscreen graphics in 32x32 and they are useless now, but I learned to deal with 32x24, except for one big problem; pfheight and pfcolor tables only seem to read the first 12 values. I've looked through the asm includes, and generated asm files, and I can't figure out how to fix this. Any ideas?

 

Also, scrolling in 1.0 sure is an awful mess. The score shakes, the colors roll, bleh. I'm running into bugs like crazy, I might just wait out a 1.1 release...

 

edit; I don't want to come off like I don't appreciate the huge amounts of work and effort that went into this release. It's definately still something I enjoy.

I don't think pfres controls the playfield resolution; if I remember correctly, it's used to help bB keep track of the playfield memory size for things like clearing the screen. The playfield resolution is set by using pfheight.

 

The playfield is 96 double-lines (which I'll refer to henceforth as simply "lines"), so 32 playfield rows would be a pfheight of 3. However, the score uses 8 lines, so the visible portion of the playfield is only 88 lines (96 minus 8 ), and 3 doesn't divide evenly into 88, which may be why you're having problems with the screen rolling. It might be possible to correct for that by adjusting the length of the overscan and/or vblank lengths.

 

Michael

Edited by SeaGtGruff
Link to comment
Share on other sites

I don't think pfres controls the playfield resolution; if I remember correctly, it's used to help bB keep track of the playfield memory size for things like clearing the screen. The playfield resolution is set by using pfheight.

 

The playfield is 96 double-lines (which I'll refer to henceforth as simply "lines"), so 32 playfield rows would be a pfheight of 3. However, the score uses 8 lines, so the visible portion of the playfield is only 88 lines (96 minus 8 ), and 3 doesn't divide evenly into 88, which may be why you're having problems with the screen rolling. It might be possible to correct for that by adjusting the length of the overscan and/or vblank lengths.

 

Michael

Never mind, I must have been thinking about the multisprite kernel, because pfheight isn't recognized by the standard kernel, and pfres does set the playfield resolution.

 

Anyway, the following example works for me. Note that the playfield statement defines 32 lines, but the last line is covered by the score, so you actually get 31 lines:

 

   set romsize 16kSC
  set kernel_options no_blank_lines

  const pfres=32

  playfield:
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  X..............................X
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  X..............................X
end

  COLUBK = $04
  COLUPF = $1A

loop
  drawscreen
  goto loop

  bank 2
  bank 3
  bank 4

 

Michael

Link to comment
Share on other sites

That example dosn't work for me, the screen rolls like mad, not sure whats up. I would think we both have the same files, so that's wierd. Thanks for the help though. Setting pfheight to 3 still only gives 12 playfield lines, just at 3(6?) scanlines tall. That DOES work. I've tried a combination too, with const pfheight = 3, const pfres=32, that gives the same rolling results. In fact, i've tried pretty much every combination, and no pfres above 24 works.

 

Any suggestions on how to put more than 12 numbers in a pfheights or pfcolors table?

Link to comment
Share on other sites

I've found the pfcolors list in the outputted asm, and by the way i'm using pfcolors background. Adding more in the asm file dosn't work. Surely Batari didn't overlook the fact that there can now be more than 12 rows? If so, it actually kinda makes the pfres command + SC useless and ugly, hope it can be fixed.

Link to comment
Share on other sites

AAARGH!! Anyone, please

 

By the way, the draw sample program dosn't work either. when I compile and run, I get a cursor and a solid playfield, the button does nothing.

I was going to suggest the draw.bas program as an example, as it uses pfres=32. To use it, you might need to tell the emulator about the extra RAM as some don't properly detect it. In Stella, press TAB, then Game Properties, and under Type, select "8k Atari + ram"

 

I'll check on the other issues in a bit.

Link to comment
Share on other sites

That example dosn't work for me, the screen rolls like mad, not sure whats up. I would think we both have the same files, so that's wierd. Thanks for the help though. Setting pfheight to 3 still only gives 12 playfield lines, just at 3(6?) scanlines tall. That DOES work. I've tried a combination too, with const pfheight = 3, const pfres=32, that gives the same rolling results. In fact, i've tried pretty much every combination, and no pfres above 24 works.

 

Any suggestions on how to put more than 12 numbers in a pfheights or pfcolors table?

The example I posted should work as is-- don't add any extra lines to it. If it doesn't work as is, then there might be some differences in our include files. Did you install bB v1.0 on top of an older version, such as 0.99? That might cause problems (I think atari2600land had a problem with doing that). Your best bet is to install v1.0 in a new folder, or completely remove any older version from an existing folder before you install v1.0 into that folder.

 

Michael

Link to comment
Share on other sites

Thanks for the help MR. I did install it in a completely new directory, far away from the old version.

 

I recompiled your example, and this time it did work, not sure what the difference was. I still can't get the 'draw' example that comes with bB to work though, even if I change pfres=32 to pfres=24. Pretty wierd. And using pfres=32 in the program I wrote and tried to use it in still dosn't work, it rolls like mad with anything above pfres=24. I can't see any reason why it would, this has to be a bug I guess. I'll have to upload the code and see if anyone else can get it working, which is pretty hard because I only have access to the internet through a laptop with no floppy drive.

 

The main thing I'd really like to know though, is how the funk do I use more than 12 amounts in the pfheights and pfcolors tables? I can't believe that batari would overlook that, is it just me?

Edited by MausBoy
Link to comment
Share on other sites

Thanks for the help MR. I did install it in a completely new directory, far away from the old version.

 

I recompiled your example, and this time it did work, not sure what the difference was. I still can't get the 'draw' example that comes with bB to work though, even if I change pfres=32 to pfres=24. Pretty wierd. And using pfres=32 in the program I wrote and tried to use it in still dosn't work, it rolls like mad with anything above pfres=24. I can't see any reason why it would, this has to be a bug I guess. I'll have to upload the code and see if anyone else can get it working, which is pretty hard because I only have access to the internet through a laptop with no floppy drive.

 

The main thing I'd really like to know though, is how the funk do I use more than 12 amounts in the pfheights and pfcolors tables? I can't believe that batari would overlook that, is it just me?

draw.bas works, and testing reveals that pfcolor tables allow up to 32 values without issues, though when pfheight is used with pfcolors, there does seem to be an issue. Not sure what it is right now but I'll look into it.

 

If you are having trouble with draw.bas and you are sure your emulator knows the binary is Superchip (this may not be automatic), the problem might be that you have old bB .asm files lingering in the same directory as your .bas file. bB will look there first for these files.

Link to comment
Share on other sites

I'll try to find a way to get my files on this computer and see what's up. There aren't any lingering bB files, and I tried adding the 'pfcolors background' to MR's example posted above, and only 12 values work, and they start in the middle of the screen. The top half, and the values under the twelve lines that work are random color values. That's without using pfheights.

 

Draw hasn't worked once for me, I get a solid green playfield and using the joystick button does nothing. Also, now when I compile any program it only compiles one out of maybe three times, with the other two times showing random garbled ascii characters. I've tried deleting everything, including old version, and reinstalling bB 1.0, nothing seems to help. I also did try setting Draw to be a superchip game, but I have the newest stella anyway and it autodetects everything else just fine, and that also didn't help.

Edited by MausBoy
Link to comment
Share on other sites

I'll try to find a way to get my files on this computer and see what's up. There aren't any lingering bB files, and I tried adding the 'pfcolors background' to MR's example posted above, and only 12 values work, and they start in the middle of the screen. The top half, and the values under the twelve lines that work are random color values. That's without using pfheights.

 

Draw hasn't worked once for me, I get a solid green playfield and using the joystick button does nothing. Also, now when I compile any program it only compiles one out of maybe three times, with the other two times showing random garbled ascii characters. I've tried deleting everything, including old version, and reinstalling bB 1.0, nothing seems to help. I also did try setting Draw to be a superchip game, but I have the newest stella anyway and it autodetects everything else just fine, and that also didn't help.

Not sure why things are messing up every so often as you describe. But I think I found the problem with pfcolors and pfheights together. I put the support into the compiler but forgot to modify the std_kernel.asm to match, so I've included an updated file. It's experimental though. Let me know how well it works and we'll go from there.

sk_pffix.zip

Link to comment
Share on other sites

I actually hadn't tried them both together yet, and probably won't because of it limiting you to one instance of each, but i'll go ahead and try out you file and let you know how it works for me. You never know, maybe it'll fix my issues with using them seperately too.

Link to comment
Share on other sites

I actually hadn't tried them both together yet, and probably won't because of it limiting you to one instance of each, but i'll go ahead and try out you file and let you know how it works for me. You never know, maybe it'll fix my issues with using them seperately too.

If they aren't working separately, I think you must have an old std_kernel.asm lingering in your working directory. You should place your .bas files in a new folder, or at the very least delete any .asm, .h or .inc files that are hanging out there.

Link to comment
Share on other sites

I already tried that. I tried deleting every file from new and old versions and reinstalling bB. I tried installing it on this laptop that has never had bB on it. Same thing happening every time. They work, but they only accept 12 amounts, and those amounts start in the middle of the screen with random colors above and below the first 12.

 

Are you sure you can use more than 12 when using 'pfcolors background' ?

Edited by MausBoy
Link to comment
Share on other sites

I already tried that. I tried deleting every file from new and old versions and reinstalling bB. I tried installing it on this laptop that has never had bB on it. Same thing happening every time. They work, but they only accept 12 amounts, and those amounts start in the middle of the screen with random colors above and below the first 12.

 

Are you sure you can use more than 12 when using 'pfcolors background' ?

Yes you can. I've attached a sample and the binary created from that sample. You should try building this sample and see if it functions the same as the included binary.

 

If they are different, you should post the .asm file it creates. That will help me determine what might be wrong.

test.zip

Link to comment
Share on other sites

Ok, this time the outputted bb.asm has more than 12 values, at home it only gets 12, but still the same bad results with the bin. Here ya go.

 

Also, tried the draw sample again after reinstalling bB again, and this time it worked fine, go figure. I didn't do anything differently than I did on my home computer, so I'm getting frustrated. And the above .bin and .asm files are from after the reinstall.

bB.zip

Edited by MausBoy
Link to comment
Share on other sites

Ok, this time the outputted bb.asm has more than 12 values, at home it only gets 12, but still the same bad results with the bin. Here ya go.

 

Also, tried the draw sample again after reinstalling bB again, and this time it worked fine, go figure. I didn't do anything differently than I did on my home computer, so I'm getting frustrated. And the above .bin and .asm files are from after the reinstall.

I definitely see differences in the binary, so something is up. But by the .asm, I should have specified that I meant the a.bas.asm file. If you can send that along, I should be able to narrow the problem down.

Link to comment
Share on other sites

Thanks for the help MR. I did install it in a completely new directory, far away from the old version.

 

I recompiled your example, and this time it did work, not sure what the difference was.

You know, I think I may have the answer to that. The pre-1.0 releases didn't use subdirectories to organize the files, but starting with 1.0, bB is using subdirectories (such as "includes") to help keep the files better organized. Well, that means if you install 1.0 on top of an earlier version-- i.e., in the same directory, without deleting everything from that directory first-- then bB will probably find all the old include files in the main directory before it ever checks the include subdirectory.

 

Michael

Link to comment
Share on other sites

Thanks for the help MR. I did install it in a completely new directory, far away from the old version.

 

I recompiled your example, and this time it did work, not sure what the difference was.

You know, I think I may have the answer to that. The pre-1.0 releases didn't use subdirectories to organize the files, but starting with 1.0, bB is using subdirectories (such as "includes") to help keep the files better organized. Well, that means if you install 1.0 on top of an earlier version-- i.e., in the same directory, without deleting everything from that directory first-- then bB will probably find all the old include files in the main directory before it ever checks the include subdirectory.

 

Michael

 

No, I meant I installed it in a completely different directory, far away from the old version, before I ever even tried to compile it. Nothing had changed between the time it didn't work and the time that it did. It's also still the only time that I've gotten anything above pfres=24 to work. It still does not in my other programs. There are NO old files anywhere near my bB 1.0, and never have been.

Link to comment
Share on other sites

No, I meant I installed it in a completely different directory, far away from the old version, before I ever even tried to compile it. Nothing had changed between the time it didn't work and the time that it did. It's also still the only time that I've gotten anything above pfres=24 to work. It still does not in my other programs. There are NO old files anywhere near my bB 1.0, and never have been.

Oh, okay. In that case, what are you using for an editor, and how are you compiling? For example, are you using Crimson Editor, or something else? If you're using 2600IDE, it uses a different compile batch file than the default bB compile batch, so you might need to be careful of that. Actually, it can use the same batch file as far as the commands inside the batch file are concerned, but the name of the file will be different, so you can copy the default bB compile batch and rename the copy to the file name that 2600IDE uses. Also, I've found (since day 1, way back when bB v0.1 was released) that the bB compile batch has a few places where it's best to add spaces in the command lines-- namely, before and after any filters, pipes, or redirections-- otherwise it seems like Windows can get cranky and not perform the command as intended. Thus, whenever you install a new release of bB under Windows, you might want to go through the batch file(s) that come with it, and add a space before and after any special symbols (filters, pipes, or redirections) if the spaces are missing. And lastly, if you install bB under a directory path that includes any spaces (e.g., C:\bB v1.0\), then you might want to put some quotation marks around any paths or variables, just to be sure there's no confusion.

 

Michael

Link to comment
Share on other sites

Thanks for the help MR. I did install it in a completely new directory, far away from the old version.

 

I recompiled your example, and this time it did work, not sure what the difference was.

You know, I think I may have the answer to that. The pre-1.0 releases didn't use subdirectories to organize the files, but starting with 1.0, bB is using subdirectories (such as "includes") to help keep the files better organized. Well, that means if you install 1.0 on top of an earlier version-- i.e., in the same directory, without deleting everything from that directory first-- then bB will probably find all the old include files in the main directory before it ever checks the include subdirectory.

 

Michael

 

No, I meant I installed it in a completely different directory, far away from the old version, before I ever even tried to compile it. Nothing had changed between the time it didn't work and the time that it did. It's also still the only time that I've gotten anything above pfres=24 to work. It still does not in my other programs. There are NO old files anywhere near my bB 1.0, and never have been.

If you are producing a different a.bas.bin than I am, something is definitely screwy. Not saying that old files are in the install directory or it's anything you are doing at all, but regardless, the a.bas.asm file will tell me what's going on so you can get working again. I need the a.bas.asm file instead of bB.asm from you because the former contains all support files that were combined together.

Link to comment
Share on other sites

Here is it, sorry about that!

OK, I think I see the problem. You do seem to have the correct support files. However, and this is odd, as best as I can tell, you seem to be running an an old version of 2600basic.exe (appears to be 0.99c). I'm not sure how this could happen unless you inadvertently copied this file over to the laptop along with your .bas files or it's lingering around somewhere in one of the directories in the %path% environment variable.

 

If you are using the 0.99c 2600basic.exe, you may also be using preprocess.exe or postprocess.exe too. If you don't find these files in the same location as your .bas files, I'd suggest doing a search of the whole hard drive and any removable volumes like floppies or flash drives to see if these files exist and are somehow being used.

 

I may be wrong in my analysis here, so if you don't find these extra files anywhere, let me know.

Link to comment
Share on other sites

On the laptop, i'm only using the postprocess and preprocess that come in the 1.0 zip on bataribasic.com

 

doing a full scan of the laptop hard drive reveals only one 2600basic.exe, dated 2/14/2007 - the same as the one in the 1.0 zip

 

As far as at home, the files are COMPLETELY seperated from where old versions were, and no old version files exist on the computer anymore; after the concastenate.exe or whatever problem, and continuation of other problems, I made sure absolutely no bB files remain on the hard drive other than the ones included in the 1.0 zip.

 

By the way, I'm Matt Risch, if you wanna add me to the 1.1 "readme thanks list", as most annoying beta tester.

Edited by MausBoy
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...