The Titlescreen Kernel

[The Titlescreen Kernel]

Is it possible to now use the 96 wide bitmap kernel with a colored background without the bars on the left?


 

[The Titlescreen Kernel]

Just realized the .PDF documentation with .bas samples is included in the text.
 

[Using Batari basic, is there a simple way to map keyboard letter presses to a variable?]

More like writing homebrew while using an emulator. Being able to map keyboard inputs to variables would allow for making a really great Bbasic program. Such as full text in games, and allowing other Bbasic users to create full text files as well.  Without the need for assembly.
 

[Using Batari basic, is there a simple way to map keyboard letter presses to a variable?]

For example, on a standard English qwerty keyboard, the number codes are a=97 A=65.

 

Is there an assembly code that could be inserted into Bbasic so that pressing the a key would set the variable "a=97" or pressing keys shift+a would set the variable "a=65" ?

 

 

 

 

 

 

 

["Ninja Kombat 2600"]

FRESHBROOD(a)Gmail,com if you'd like to help contribute to this project via PayPay. Anything helps.
 

["Ninja Kombat 2600"]

Thanks guys! This Covid has made life hard, I've been out of work, but just started playing with the music again. (I could REALLY use some help with short simple beats that loop if you'd like to help) but I will get back to working on this soon! Your encouragement is motivating!
 

[DPC+ Collision Example Program]

Hello RT, everyone again. I am just now starting to get into the DPC+. About collision, is this mainly only good for, say, P5 vs. playfield? Is there collision for say, P5 vs. P6 now?
 

[7800 Question]

Hey- Can Bataribasic be used to code for the 7800? And is the coding for the 7800 completely different from the 2600? I have a rudimentary knowledge of using Bb to write 2600 games. Would I be able to jump to 7800 or no?

["no_blank_lines" and scanline count]

Is there an existing Bbasic tutorial program that deals with manipulating scanlines and cycles? As a noob I understand the rudimentary process but have no idea how to implement it or take it into account, other than "If program wiggles, reduce code/routine size".  Particularly taking advantage of vblank and overscan maybe?

 

Like I kinda get what it is, but not how to use it. I can read RT's EXCELLENT help page all day, but I find the easiest way to learn is to reverse engineer very simple existing .bas files. Without those examples I find it really hard to implement anything useful. I'm reading this https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#vblank 

 

but I'm still not sure HOW MUCH code I can put into the vblank, not that I've tried it yet. A very simple 2 bank example .bas would be super duper helpful. Thanks again to everyone for all your great help and input!



 

[VisualbB : Pasting small snippets of code causes perpetual scrolling which crashes the program]

Thank you!
 

[Bug Report Thread]

^{Version 1.0, build 568, Win7 64bit.}

 

^{Whenever I post even a small line of code the program will endlessly scroll up then freeze and crash. Am I doing something wrong? It's making me crazy!}

 

^{Also, in forums, I see that I can edit a post but is it possible for me to delete a post completely? I only recently started posting here and sometimes I reply in the wrong forum. I don't want to be annoying.}

 

^{Thanks for any help.}
 

[Version 1.0 build 568, posting small snippets of code causes perpetual scrolling, crashing]

I'm on Win 7 64bit. About half the time whenever I paste a small line of code, the program will scroll up endlessly and then freeze and crash. I have to close it and start over. This is driving me crazy.

 

Am I doing something wrong? Are there newer files I can update to get rid of this issue? Any help is appreciated.
 

[VisualbB : Pasting small snippets of code causes perpetual scrolling which crashes the program]

Version 1.0 build 568 on Win 7 64 bit, often (about half the time) whenever I try to paste even a small line of code the program will scroll endlessly and crash.

 

Am I doing something wrong? Is there a newer version of Visual bB I should be using? This is driving me crazy.

 

[if-then or if…then?]

Speaking of if.. I've been told not to use 2 or more in the same line. Why?

 

For example:

 

 

  if player1y<76 then e=14 : if f{1} then e=13

 

vs

 

  if player1y<76 then e=14
  if player1y<76 && f{1} then e=13

-----------------------------------------------

Both of these examples seem to work perfectly fine in my code. The top example uses less memory.

 

But I have been advised to never use 2 or more if statements on the same line.

 

Why?

 

Is it because it's generally bad practice and can lead to confusing code?

 

Or does it actually cause a glitch and make the game crash upon reading? Because in terms of memory usage, if the top line reads correctly every time, obviously it would be preferable.

[Using 2 or more if statements in the same line.]

Example:

 

 

  if player1y<76 then e=14 : if f{1} then e=13
 

vs

 

  if player1y<76 then e=14
  if player1y<76 && f{1} then e=13

-----------------------------------------------

Both of these examples seem to work perfectly fine in my code. The top example uses less memory.

 

But I have been advised to never use 2 or more if statements on the same line.

 

Why?

 

Is it because it's generally bad practice and can lead to confusing code?

 

Or does it actually cause a glitch and make the game crash upon reading? Because in terms of memory usage, if the top line reads correctly every time, obviously it would be preferable.

 

 

 

 
 

[Arguments not working for stack or bit assignment]

I'm sorry, thank you for trying but I am still so lost! If I need an ammo count or life, I literally just write "a=100" for 100 bullets or "b=100" for 100 health. I have no idea if its in front or back, pushed or pulled lol. I only understand that a through z can each have up to a 255 number assigned to it, or be broken down into 8 "on of off" bits in the form of [0] through [7]. That's how I've used them so far and they seem to work for me. This front/back/push/pull/stack stuff is totally Greek to me.
 

 

And in the standard kernel it doesn't seem to matter when or where you create the variables, they are globally read regardless of which bank the program currently reads from.
 

[Arguments not working for stack or bit assignment]

43 minutes ago, KevKelley said:

My noob understanding is that the stack is a part of the the memory where you can store a variable's value and then retrieve it later on.

My noob understanding of using variables is you say that a=5, and a equal's 5. I don't even know what it means to "store" and retrieve" later on. If I use DPC+ can I not simply use variable like I do in the standard kernel? I feel like I'm just starting to have a novice/intermediate understanding of the standard kernel and DPC+ is almost like learning a new version of batari.
 

[Arguments not working for stack or bit assignment]

Would someone please explain to me in laymen's terms, as a noob, what "stack" means? I am just now starting to play with the DPC+. So confused. Sometimes I think you programmer guys don't realize your level 1 is a noob's level 3 when you explain things. I have no idea how to use stacks, data tables, or make a playfield scroll continuously scroll in either direction while drawing new blocks. 
 

[Using assembly in BBasic to edit p0 pixels?]

Who would we talk to about this to hard code into the next update of bbasic? I think we all agree in theory it seems very plausible.

 

[Using assembly in BBasic to edit p0 pixels?]

25 minutes ago, TwentySixHundred said:

ypos could be limited to 255 from 0 @ top to whatever the programmer desires further down the sprite. That way the full sprite length can be utilized as per normal functionality. This would allow for "scrolling" sprites to be changed on the fly using code for pixel flipping rather then a sequence of animated sprite data.

 

So for instance you could have "player0pixel 7 200 flip" and have that sprite move upward meaning when the 200th line makes an appearance bit 7 on line 200 would be active. For the next complete scroll the programmer could have the pixel deactivated. This would give the illusion much like scrolling playfield does.

 

Either way this would open many possibilities

At the very least you could have a village full of different and unique NPC's, almost countless, using the same default sprite that has temporarily altered pixels inside each shop or house you enter.
 

[Using assembly in BBasic to edit p0 pixels?]

22 minutes ago, Random Terrain said:

 

I wasn't talking about my program, I was talking about the original RevEng program it was based on. He puts the sprite in RAM, then you can fiddle fart with it in whatever way you want. A sprite in ROM can't be changed.

Yeah I certainly do not know enough to fiddle fart with it. I was thinking maybe it just creates a temp copy in ram only for that one drawscreen command then goes right back to reading the default rom sprites unless that command is used again. It would only temporarily change the sprite. And maybe it could only be used for one sprite at a time as per ram, instead of changing multiple sprites at once. That would be an amazing implementation into the core bbasic program if possible.
 

[Using assembly in BBasic to edit p0 pixels?]

I can't see why this couldn't become part of the base code for regular bbasic, without even needing to use DPC+. The only thing I can think of is it would have a limit of 0-7 for the x, and maybe 99?-0 for the y.

 

 

player0pixel, __Standsprite, 7 97 off

 

 

 

__Standsprite

   player0:

  %00000001

  %00000000

  %00000000

end

 

would result in turning that single 1 to a 0 and make the sprite invisible. (assuming the default height is set to 99)

I would think it would be temporary read only, like setting the direction each time within the loop.
 

 


 

[Using assembly in BBasic to edit p0 pixels?]

Yes exactly. I think the easiest way to implement it would be exactly like that- even if early limitations meant no bankswitching- it had to be used within that same bank, or there was a height limit on the sprite.
 

There are so many uses for it. Make sprites "vanish" into thin air as they disintegrate, shrink up (the opposite of decreasing p0height) have static NPC's constantly blink an eye, tap a foot, or open and close their mouth when they talk, etc.. That one tiny feature would make the graphics look amazing, both for static and animations.
 

[Using assembly in BBasic to edit p0 pixels?]

I have no clue how you would or could implement that, I'm still learning bbasic and don't know any assembly... but it seems logical that some type of assembly code could read the raw basic data, starting at a particular player0: then add however many y coords and 0 through 7 x coords to land on a 0 or 1 within the sprite graphic, and toggle that on or off- without having to redraw an entirely new sprite or jump to another separate sprite.

 

 

I mean something similar to pfpixel, but instead p0pixel (label) x, y on

 

Where p0pixel is the built in routine syntax which then jumps to that label, then reads down stopping at the first player0: and counts the pixels down then across within that sprite.


 

[Using assembly in BBasic to edit p0 pixels?]

I think it would be an immensely useful feature that could potentially add "extra" graphics while saving graphic memory. I'm surprised no one has done this yet. For example I am making a Mortal Kombat clone, but due to limited memory I use the same body type for every character using const/playerhi/low, but only change the color when a new "fighter" is selected. It would look amazing if with that new color pallet, maybe just 2 more pixels could be drawn within the unused 0's in that sprite at that time, to maybe add a "pony tail" or hat. Those tiny, subtle differences combined with changed colors would give the illusion of an entirely new sprite, even though it's the same sprite every time with just a couple pixels turned on or off after the code reads the default sprite.