bB with native 64k cart support - 1.1d.reveng

[iesposta]

For your Titlescreen 1.2 in DPC+ games, what score .asm needs edited to customize the font?

Can Titlescreen fonts even be changed in DPC games?

Can I use one font for the Titlescreen and another for the DPC+ game?

I can not make the 8 into an "m".

Score exists in the Titlescreen 1.2 folder and in the Project \ Titlescreen folder.

VbB never remembers what you set.

Do I point it to the project folder, or the Titlescreen folder in the project folder, or the asm folder inside that ? Where should the source and destination be pointed?

[RevEng]

For your Titlescreen 1.2 in DPC+ games, what score .asm needs edited to customize the font?

score_image.asm

 

 

Can Titlescreen fonts even be changed in DPC games?

Yes. The Titlescreen Kernel acts independently from the kernel you're using, with the exception of some of the memory it steals from the kernel.

 

 

Can I use one font for the Titlescreen and another for the DPC+ game?

Yes. The titlescreen bank has its own independant font, courtesy the score_image.asm file.

 

For setting the titlescreen font style, use "const fontstyle = [A font name or # from score_image.asm]"

 

I can not make the 8 into an "m".

Score exists in the Titlescreen 1.2 folder and in the Project \ Titlescreen folder.

VbB never remembers what you set.

Do I point it to the project folder, or the Titlescreen folder in the project folder, or the asm folder inside that ? Where should the source and destination be pointed?

Sadly, I'm not a regular user of Windows so I don't use vbb.

[iesposta]

What would be the command line command arguments to just make the "titlescreen.asm" ??

 

(I find VbB Titlescreen Wizard ignoring my font choice, as well as forgetting where the source /destination is.)

[RevEng]

You should "include" it in your basic file. After that you just compile your basic source per usual, with "2600basic.bat mygame.bas" or "2600basic.sh mygame.bas", depending on your platform.

See the included examples in the Titlescreen Kernel zip for the "include" and dir structure. Also, the docs cover manual usage.

[+Gemintronic]

Hey! Another thing to include is RevEngs excellent playercolors kernel.

http://atariage.com/forums/topic/212102-standard-kernel-mod-colorplayers/

 

Couldn't that be dropped in as just another kernel option?

[RevEng]

Thanks for the compliment! As it stands that hack doesn't play nice with kernel options other than those used in the demo, so it would be a bit more work than dropping it in.

 

I'm going to stick to my feature freeze from here on out, and just fix any reported bugs. I'll likely be changing my career path very soon, so I won't have the time to do bB any justice. Time to let batari take the reigns back, or if he doesn't eventually take over again, then someone else.

 

I think we're in pretty good shape for a freeze anyway. We now have a common bB zip with binaries for all supported OSes (without previous problems under 64-bit Windows), the 64k cart format is working great, DPC+ is mostly ready for prime time, I added docs for setting up bB development environments, and I think I've managed to knock off a lot of the rough edges that people complained about.

[+Random Terrain]

My antivirus program claimed that bB.1.1d.reveng23.zip was suspicious and refused to let me download it. I didn't have that problem with any of the other versions.

 

 

http://www.im-infected.com/virus/win32evo-gen-susp.html

Win32:Evo-gen [susp] is a perilous type of virus that opens a backdoor on the infected computer. This malware may allow an attacker to access the target PC from remote places. Once it enters the computer, it can perform various operations that may be harmful to operating system. Sensitive data from infected computer is also at risk with the presence of Win32:Evo-gen [susp]. Identity theft, file changes, key-logging, and exploitation of the computer for ‘bot’ operation are just some of the payloads of this virus. Though, not all variant carries these payloads in a single code.

 

 

 

[RevEng]

Well, it's definitely a false positive. The Windows binary is generated on my Linux laptop and never touches a Windows box prior to getting zipped.

 

I'll see if I can do something to shake the false positive.

[+Random Terrain]

Well, it's definitely a false positive. The Windows binary is generated on my Linux laptop and never touches a Windows box prior to getting zipped.

 

I'll see if I can do something to shake the false positive.

 

Avast probably just added some new thing because I restarted my computer, ran VbB and when I went to compile a program with version 22 of bB, Avast sent 2600basic.exe to the virus chest.

 

 

So it's something new that they did. When I right click on that file and scan it, Avast says there is no virus.

 

I excluded the whole Atari folder using this info:

 

youtube.com/watch?v=5LUIdW7oOhU

 

Now I can compile again.

 

I also put this in the exclusion list for the Web thingy:

 

http : / / atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=*

 

Now I can download your file.

[+Gemintronic]

My illusions of grandeur detector has been red flagging his multi kernel and 64k support for quite some time. It detects another Atari 2600 RPG idea infecting my system.

[+Gemintronic]

I tottaly missed the fact pfscroll works now! Er, people have been talking about scrolling up or down only.. does that mean

 

pfscroll left

pfscroll leftleft

 

or

 

pfscroll right

pfscroll rightright

 

is not available?

[+Random Terrain]

I put the scrolling info that RevEng posted here:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_pfscroll

 

I still need to post a small example, though.

[+Gemintronic]

I put the scrolling info that RevEng posted here:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_pfscroll

 

I still need to post a small example, though.

 

Horizontal movement (left/right) is not mentioned at all. It's not clear if it's an omission or not possible.

[+Random Terrain]

 

Horizontal movement (left/right) is not mentioned at all. It's not clear if it's an omission or not possible.

 

I'm sure RevEng will reply when he gets a chance, but until then, it looks like he just had enough space left to do up and down.

[+Gemintronic]

 

I'm sure RevEng will reply when he gets a chance, but until then, it looks like he just had enough space left to do up and down.

 

yeah, it's looking more and more like it's vertical only. The new way to pfscroll sounds alot like adjusting the playfieldpos variable in the standard kernel. You couldn't really mix and match using playfieldpos with pfscroll left or pfscroll right.

[RevEng]

Bang on, RT. I only had enough space to do vertical scrolling. Horizontal scrolling would have used up too much memory, as I am literally a few bytes away from stuffing the DPC+ ARM code.

 

Sorry, I should have made this more clear when I released the code. If somebody does try pfscroll horizontal commands with DPC+, bB should spit out a message about it not being supported.

 

The new way to pfscroll sounds alot like adjusting the playfieldpos variable in the standard kernel. You couldn't really mix and match using playfieldpos with pfscroll left or pfscroll right.

In this case it's not working for space reasons. The DPC+ pfscroll # command really does shift the playfield memory instead of just changing a pointer.

[+Gemintronic]

I guess the only hope for horizontal scrolling is for SeaGtGruff to port his gynormously useful pfhscroll.asm library to DPC+

[iesposta]

BUG REPORT

PF commands that use the ARM routines with values out of range, rather than failing gracefully or being ignored, crash both Stella and the Harmony.

I have checks in my programs, but oftentimes I am still getting crashes.

Here is a screenshot.

Jumping off to the left - it is probably checking PFREAD for a pixel, but off the left is "less than zero."

 

In my Q*bert the routine to change the PFPIXEL in the bottom left crashes because it is trying to turn on or off pixels "less than zero."

Even with checks in place, sometimes it crashes both Stella and Harmony Cart.

 

Is there an easy fix to just ignore "out of range" operations?

 

[RevEng]

BUG REPORT

PF commands that use the ARM routines with values out of range, rather than failing gracefully or being ignored, crash both Stella and the Harmony.

Yeah, there's no room left for range checking.

 

The non-DPC+ pfpixel command doesn't range check either and out of range operations can sometimes cause the 6507 to crash, so at least its consistent.

 

Thinking about it some more, it's just as well a DPC+ out of range PF operation causes a dramatic result. That way it's pretty obvious you've done something wrong and can fix the bug before the game gets released. If it silently failed, buggy code would likely persist.

[+Gemintronic]

Is this something bblint could be rigged to detect?

[RevEng]

Since the pfpixel location is almost always going to use a runtime game variable, its not something that can be caught at the lint stage, or even the compile stage.

[iesposta]

Is there any "special way" to detect collision between player0 and player1 in DPC+?

Because as soon as you do this:

if collision(player0,player1) then "do-something"

ALL virtual players 2 thru 9 will be detected.

In other words all virtual player collisions with player0 will "then do the something" the above line does when the programmer really only wants to check player0 with player1.

 

collision(player0,player2) thru collision(player0,player9) work just fine.

 

collision(player0,_player1) does not compile.

 

Just asking if I missed something -- or we will have to make a point about using player1 for something that is not "collision checked" as all virtual players are affected.

Of course I know all virtual players are player1, but I just ran into this "exception" (unless I am coding it wrong).

Thanks.

[pitfall_jerry]

Errors with Unsupported 16-bit application - preprocess.exe cannot start or run due to incompatibility with 64-bit versions of Windows. I downloaded the latest version of bB.1.1d.revenge23.zip. Trying to setup new Windows 8.1 64-bit system.

Edited November 7, 2013 by pitfall_jerry

[+Gemintronic]

We should probably start working on a community set of soft collision functions.

[+Random Terrain]

Errors with Unsupported 16-bit application - preprocess.exe cannot start or run due to incompatibility with 64-bit versions of Windows. I downloaded the latest version of bB.1.1d.revenge23.zip. Trying to setup new Windows 8.1 64-bit system.

 

It works on my Windows 7 64-bit system. You might want to right click and set the compatibility mode to something other than Windows 8 if you are having a problem.