grafixbmp

Hello everyone, been a awhile I know. I've recently started a new lob and have gotten settled in rather well, I have a bit more free time lately so ive been able to spend more time back on this lately. I'm currently working on 2 things at the moment. I'm prototyping a text kernel for bB and getting back to my first roots of catlevania. I've made a few upgraded changes to the kernel layout and wanted to share a quick mock image. With this latest of changes, I am now going to release some working code soon to show the first level screens without the hud (as of yet). The changes proved necessary to recoup some of the RAM and seem to work out ok. Albeit the screens will now appear a bit more blocky than they were, they still have the level of detail I like and will feel right once sprites come into the mix. I hope everyone will be ok with the newer screen designs and I thank you for your patience in waiting so long for a demo bin. This will be the year for REAL progress. This image depicts the latest in a long line of kernel designs now only requires 40 bytes of RAM to render this screen or any other.

I have an idea for ya since your design is similar to my castlevania work. The technique i'm using for creating the many different screens could be adapted to horizontal scrolling and save you more space than mine does. What i've been doing is loading a list of index values into ram and the area of the kernel that handled the playfield would load from the list of index values by using Y as a scanline counter to go through the list and the index value would be in X for the playfield data. Then the playfield portion of the kernel just loaded from each page for each section of the playfield. page A is the color of the scanline page B is PF1 left side page C is PF2 left side page D is PF2 right side page E is PF1 right side With all these loading from the same index, everything lines up fine for a total of 256 individual scanline data. The index list loaded into RAM handles the overall screen image. Once this is done, load 0 into the accumulator and turn the playfield color to black and blank out PF1 and PF2. Changing the playfield color to black at the right time causes PF0 which is already 1111 to be black while blanking the next scanline of any data and it will keep PF0 black while the next scanline handles nothing but sprites. I also have several cycles left during the PF section for other things nd the Y value in mine decrements every 2 scanlines instead of every scanline. This is what I did: Scanline start ;11 cycles free ldx 80,y ;4 lda fa00,x ;4* sta PF1 ;3 lda fb00,x ;4* sta COLPF ;3 lda fc00,x ;4* sta PF2 ;3 ;7 cycles free lda fd00,x ;4* sta PF2 ;3 begin on cycle 48 lda fe00,x ;4* sta PF1 ;3 dey ;2 ;5 cycles free ; blank out playfield lda #0 ;2 sta PF1 ;3 sta COLPF ;3 sta PF2 ;3 ;1 cycle free ;scanline end As you can see I haven't killed the free cycle areas with any code yet. But it fills all 76 cycles of a scanline and sets up the next scanline for sprites. One way you could get your scrolling is simplify for detail and pre-render all the horizontal movements you want to design and have them fill up a few pages. I said ya could do it and take up less data than mine. Here's how. All you would need is atleast 2 pages of data to get quite a few variations of PF data. The key to your type though, is having 2 index values stored in RAM (as compared to my 1 per instance) which reference diffrent parts (left and right sides). The entire height of the ground type object you want to draw can reference those 2 index values for all of it since it doesn't have to change from the top of it to the bottom unless you want it to, you won't need near the huge list mine does in RAM. One difference you would need would be for your PF color loading. I had mine builtinto the same system for simplicity, but you may want to do that differently for more detail each scanline (same visual data, different color). The horizontal movement would just be changing out your index tables in RAM for every frame it needs to change for movement. (for both vertical and horizontal movement) So this way all of your movement is simply processed by changing the set of index values you store in RAM. In mine, I will be using superchip RAM and for such a game as yours it would be advised as well.

Then, would it be typical when 2 operands are present as such, one of them will change and the other will not? The one changing being what is looked for?

If you want your readers to understand what is meant when saying "operand", it should mean finding a simple definition that explains what is going on with an example then relating that definition to the jargon word that is commonly used, covers both avenues. Understanding what is going on and supplying one word that labels the concept. That word being agreed upon by the general consensus. I got one for ya: (j/k)an Operand is the part of a computer command that is worked on and becomes the result of the command. Example: A=A+1 In the example, the + represents the command or opcode being done The A is the operand it is done to. And the 1 is the operand it is done with.

As far as I know, bBWin7_64bit.zip is the latest, most up to date version of bB (before the 10 sprite beta version). If you're using that, it should work. Whenever I have trouble, it's usually with touchy if-thens. This thin line (icing) trick will become obsolete when we all move on to the version of bB that has 10 multicolored sprites, but we can have fun with it until then. This only means everyone who wants to play on real hardware MUST have a Harmony using DPC+. And using new a version of stella will also have the emulated ARM processor when necessary. So Harmony, DPC+, New DPC+ bB kernel, new version of stella, Thats alot of new things for everyone to have to go to just to use the new version. I see this as more of a new option rather than a forced upgrade. bB should still support all the previous kernels. It should now be: standard kernel, no blank lines kernel, multisprite kernel, and now DPC+ kernel. I don't see why the older kernels would be obsolete but rather a new more advanced option has been added to the tool set. Besides, If the older kernels do go obsolete like ya say, you still need to get a Harmony so you'll be able to run DPC+ games on real hardware if you haven't already. You once said you hadn't got one yet.

Everytime now that I try to compile any one of your platform program, it hangs at a syntax error in this line (578 with the latest source): on Frame_Counter gosub Frame_00 Frame_01 Frame_00 Frame_02 It compiled yesterday but now it won't. the compiler is way to finicky/picky. I even switched which 2600basic.exe I was using and still the same thing. If ya breath too hard on the computer it will throw back an error. I got a simple playfield to display. I was tryin out that skinny line thing. I'll throw it up here. example.bas example.bas.bin

Man that is the funniest /scariest thing all day, I was just watching He-Man on youtube channel before I came here. I remember that game of Heman too. I always liked LCD games . I even designed a few LCD game screens back in the day. SMB2, sonic spinball, and a few others. I even tried to reconstruct donkey kong junior based on some screen shots from a game magazine.

Don't do that, you need that arm to code with.

Was curious about sliding while squating. Like run right then squat while slowing down (sliding)? Just an afterthought.

Thanks RT. I get it now. I was way over thinking it and this whole time it was so simple

Ha! This whole time I didn't realize he could squat. I like runnijng right up near the edge and have him slide only to fall off the edge very gracefully. Your code explained to me and gave me appreciation in one go of how PFreads work. I love it. I still don't get how ya do the variable playfield line thickness thing.

IT'S PERFECT! That feels so natural. Very high quality. Just curious, if yours doesn't have any complicated math going on, then I'm guessing there's plenty of room for adding many other things for any gind of game the engine would be used for? I may play with this one. I smell mario bros 2 (not super). Ok. This may be a stupid question... I follow most everything in the code except for one thing, I never understood how ya alter the thickness of sections on the playfield. I figured there was a provision for it but I can't find it in the code nor have I ever figured it out before. And when ya set the colors, whats the purpose of setting the PF color, then pulling the color data from the list immediately afterwards?

Thanks for pointing that out. I probably forgot to clear the jump code when he bangs his head. Yep, that's what I did. I forgot to clear the appropriate variables when he bangs his head. The improved version is in the first post. The movement is spot on however, holding the button works differently between being in the open and being under a platform. In the open, its one shot when holding the button. Being under a platform it is repeated jumping.

Boy I like that! Especially your little skid feature. Almost has a SMB feel to it. He does move a bit quick. I guess your code is scalable for speed though. Don't know if this is anything or not, but when you jump in the open it seems strait forward but when jumping under a platform, the little guy pauses as if he went all the way up before he falls.

Here are a few simple examples of a 3d corridor, a cloud scape for a flight game and a star scape for some blocky outer space battles. There are many others examples especially those that aren't mirrored vertically. The beauty in it is the ability to scroll and draw consecutive animated playfields. As far as the cloud cover one, it kinda makes me think of a possible afterburner clone sans the tilting.

I guess you mean the focus is on DPC+ kernel now.

Yes. It is because it is done in the TIA hardware. I mean a vertical mirror not a horizontal one. Where you would have: PF pixel data: line 0 line 1 line 2 line 3 ~ line 10 line 11 line 11 line 10 line 9 line 8 ~ line 1 line 0 or they could just do 0 through 11 twice. This way ! A V ! A ! ! V not this way -><- <--> Even spit screen gameplay could be possible this way if var 44 through 47 were used for extra ploted sprites. If horizontal scrolling is still possible, howabout a simple horizontal rail shooter similar to vanguard or R Type?

Hello everyone, I've been playing a bit with bB and had an interesting idea. I've sent batari a question about it, but I wondered what other thought about this kind of kernal option if posible. Howabout the ability to verticaly refect your playfield from the standard kernel? It could draw all 11 rows half way down the screen then draw the data in reverse to make a mirrored image. This actualy appears to double the vertical resolution by reading from the same RAM. It could even have the option to do it without mirroring. This could be great for starfields, 3d corridors, and even moving cloud cover for flight simulators. Nonmirrored could be used for more detailed platformers having the top and bottom sections the same. This might work well since it reads from the same data without much if any overhead in RAM. Any thoughts?

I found it! Lumpies of Lotis 4 is playable in your browser here http://lumpiesoflotis.com/cgi-bin/lumpies.cgi Its rather neat. I still haven't got past the first level. More inspiration, I love it!

I think you may have successfully stumped everyone with this. Not being familiar with the toy at all, I searched around a bit, but couldn't find any pics showing the screen, or even a video... no surprise there. As you probably already know, A 3D maze game is possible as seen with or by Eric Ball. A game that looked like that Spyro one who be nice to see. Here is an amazon link with images of the games but none of the screens. http://www.amazon.com/gp/product/B003XUO4GK/ref=as_li_ss_tl?ie=UTF8&tag=atariage&linkCode=as2&camp=1789&creative=390957&creativeASIN=B003XUO4GK Yes, I've played skeleton and even merlin's walls all of which are great games. The 'inspiration' I was getting from this game, led me back to and old game I discovered when I was a young teenager in an old computer programing magazine called "Lumpies of Lotis 4". There never was a 1 2 or 3 Ththe name was just completely random. It was written out in I think GW basic for IBM PC junior. I had tried to get it working on a Tandy long ago but to no avail. I tried to take the games description and images as a template for programing it in basic for a commodore 64. I got many of the graphics done, but back then my logical mind wasn't very logical in that I couldn't figure out how to store data in tables and arrays for maze navigation. However I figured out that I could draw out every possible screen that would be seen in the maze world which totaled around 32 screens. Nothing had to be processed just displayed from the list of images. Between the way LCD games work (prerendered screens with everything about the game present) and the way I was doing the old game Lumpies of Lotis 4, a rather advanced looking 3d maze could be done with bB. If The screen was virtually sectioned by 4 collumns (byte width) and 5 to 7 sections tall as a grid, then as one would move through a maze, there would be spaces of the maze each having 4 major directions depending on which way you were facing. Each space in the maze has a small list of addresses which tells the memory reserved for the screen which groups to load to 'build' the screen for the area you are in. I even wanted to throw in the ability to have sub 45 degree transition shift instead of just strait 90 degree 4 directions.

Ok the 2600 graphics chip "the TIA" has only a few graphical properties. For general bB use there are player0 and player1 each being 8 bits wide. there are 2 missles only one bit wide. and a single bit ball for a total of 5 objects. Thoes objects can be modified with control registers listed on Random Terrain's bB guide website. You can duplicate both of the 8 bit wide player graphics to make copies of themselves you can even stretch a single sprite too. These copies position themselves to the right of your actual sprite location and do so as 2 or 3 repeating what you have set as that particular graphic. The spacing of the copies is predefined in the hardware but the are several options. If you position player0 somewhere on the screen and position player1 8 spaces to the right of it and activate the repeat settings, they automaticaly create the copies for you. Then you need to use the ball or missiles as a cursor and then check the cursor's position to know which hex block it is over. There are several examples in the batari Basic section of the forum. They are code snipets which preform some of the basic things in programing a game. The one thing to remember is when you set up what you want to be shown and run conditions and such then you must "drawscreen" and the changes will be made. you can have more than one drawscreen in a program but you must always make your program loop. For every pass through your loop, you begin to change minor things about what is being shown. But remember that there must be 60 drawscreens a second which means that your game code shouldn't take too long between "drawscreen"s As a quick example, if you change the location of a graphic every other drawscreen then change it back the others, you effectively add another graphic to your screen but this produces flicker which is one of the classic 2600 staples among many other consoles.

How did you make that picture? im using vbB, and cant get anything close to resembling what you made... Well, with vbB you dont get the full range of the playfield and you have several limitations with the standard kernel sprites. You 'can' get something similar by brute forcing it. Activate your multiple copies and set the positions so that you have alternating layout with one player set to 3 close and the other to 2 close then setup your sprite as a tall one for both having many of the hex images in a row vertically then just have the player set to 3 draw them and the player set to 2 "being in between the 3" display the same thing but offset by have tall hex space. This way you only get either one color if both are set to the same thing or alternating pattern of 3 blue and 2 red. There are limitations which limit what you can produce but you 'can' create some intresting patterns. As far as the plafield, it gets chunky but it can work. Here is an example of what vbB version could look like.

Never noticed this before and it may be because I wear glasses but the red hexes appear to float in 3d above the blue ones. Man I love optical illusions.

I found your idea inspiring and drew up some quickies in 5 min thought I would drop them in. Have fun!

OK got a crazy idea from a McDonald's toy. Once upon a time Mc D's had about 5 or 6 handheld LCD videogames. They have actually done this a few times and for one of thoes times the theme was SEGA ips one of which was spyro andwas the most elaborate for a cheap toy. Anyway I have one and the unique thing about it is it was in color and you had to pass light through it to see it. there was a pullaway panel so you could play inn the sunlight. To top it all of it was a 3d maze game. Some of you may know of this game. Well, I decided to draw out this digital screen because I go the idea of doing a 3d game engine based on the principals of so-called "sectioning off" areas and enough areas in a table can be called up to render as such. Anyway I wanted to post this pic hoping others could see what I see in the potential of inspiration from it I was getting. A bit of a correction to above. These were NOT SEGA characters. They were Crash Bandicoot and Spyro. There were 8 games in all and were released for McDonalds through Universal Interactive. Spyro was developed by both insomniac games and Universal. It was released in the US under Sony, However for America it is known as Sony Computer Entertainment America Or hence SCEA Which can easily be mistaken for SEGA at first glance. This was my bad. This toy was relesed in 2005.