Art Guff

[Estlib]

So far one only. this isnt a programming project as im not able to but its drawn in a way that should be possible in batari basic.

The mockup is 320x192 where 160 was doubled to give more tv-like appearance, so 16 pixels wide area on the mockup is actually only 8 pixels wide.

Edited January 9, 2015 by Estlib

[Jinroh]

Cool, always great to see platform game things. Something like Giana Sisters or Princess Rescue?

[Estlib]

Cool, always great to see platform game things. Something like Giana Sisters or Princess Rescue?

yep, added a neat gif

[Jinroh]

Oh wow, that bunny character is adorable.

[Estlib]

cave/volcaNOPE

Edited January 9, 2015 by Estlib

[Estlib]

Cant edit last post so, gif volcano with slightly different sprite and a different flickering look

[Sprybug]

Cant edit last post so, gif volcano with slightly different sprite and a different flickering look

pbgif2done.gif

 

Yeah, Batari wouldn't be able to do this with this much detail. Something like this would definitely have to be done in Assembly. You said you would use flicker to be able to create all the detail that you have. This would mean that the game would run at best 30 FPS and would need a lot of CPU time to draw up all these screens. This is not including all the other programming for everything else which would also eat up a lot of CPU time. You'd probably have to do what I did and use an entire CPU game cycle to do all the other stuff and redraw the same screens at least once more before advancing and because of the flicker technique, that's another 2 screen draws in the entire scope of things. The atari 2600 draws the screen at 60 FPS, flicker would bring it down to 30FPS, and the technique I told you about would knock it down to 12 FPS essentially. Princess rescue gets knocked down to 12 FPS when you kick a turtle shell and you know how slow it goes when that happens. I squeezed as much as I could out of Batari without doing inline Assembly for my games. So if you do something like this in Batari, you're gonna have to scale back. What you saw with PR and Zippy graphically while still being able to use Batari's horizontal scroll routine, is about as good as you can get. Your graphic resolutions, modes, etc, can improve in Batari, but you lose the ability to horizontally scroll and with my games that's "no good", which is why I always stick with the standard kernel. I've explored the other kernels, DPC+, etc, but you always lose horizontal scroll with those enhancements.

 

But I really like your art! I wish you could do something like that in Batari. It'd be a huge undertaking to even pull it off in Assembly.

Edited January 20, 2015 by Sprybug

[Estlib]

 

Yeah, Batari wouldn't be able to do this with this much detail. Something like this would definitely have to be done in Assembly. You said you would use flicker to be able to create all the detail that you have. This would mean that the game would run at best 30 FPS and would need a lot of CPU time to draw up all these screens. This is not including all the other programming for everything else which would also eat up a lot of CPU time. You'd probably have to do what I did and use an entire CPU game cycle to do all the other stuff and redraw the same screens at least once more before advancing and because of the flicker technique, that's another 2 screen draws in the entire scope of things. The atari 2600 draws the screen at 60 FPS, flicker would bring it down to 30FPS, and the technique I told you about would knock it down to 12 FPS essentially. Princess rescue gets knocked down to 12 FPS when you kick a turtle shell and you know how slow it goes when that happens. I squeezed as much as I could out of Batari without doing inline Assembly for my games. So if you do something like this in Batari, you're gonna have to scale back. What you saw with PR and Zippy graphically while still being able to use Batari's horizontal scroll routine, is about as good as you can get. Your graphic resolutions, modes, etc, can improve in Batari, but you lose the ability to horizontally scroll and with my games that's "no good", which is why I always stick with the standard kernel. I've explored the other kernels, DPC+, etc, but you always lose horizontal scroll with those enhancements.

 

But I really like your art! I wish you could do something like that in Batari. It'd be a huge undertaking to even pull it off in Assembly.

:C too bad i completely failed with it then though. and btw, flickering wouldve been used for sprites only. and the screen colors change every 10 or 6 frames to animate the = blocks

[Sprybug]

:C too bad i completely failed with it then though. and btw, flickering wouldve been used for sprites only. and the screen colors change every 10 or 6 frames to animate the = blocks

I see, then maybe the FPS wouldn't be as bad then. I thought you were doing it for the entire playfield. I was wrong about 4 drawscreens in a game cycle being 12 FPS, it's actually 15 FPS. 5 drawscreens would be 12 FPS. Don't let this fact though deter you. Take your ideas and figure out how they would work in Batari if you end up using that. It's what I did with Princess Rescue. I had a lot of ideas for it, but found out how I was limited so I did the best I could and worked around them. You can still have the same layout that you do, just may have to back off on the detail and graphics. On the standard kernel, you only have 11 playfield rows to work with, so keep that in mind if your going to make a horizontal scrolling game. In Princess Rescue, I made them all even so I could do multiple colored blocks, which is what you are going to have to do. If they were all the same color (like in Zippy), then you can change the width of each row. That's why Zippy and PR have the look they do. The blocks in Zippy have different heights because I use the same color, but in Princess Rescue the blocks are all the same size because I wanted to use different colored blocks.

[Estlib]

I see, then maybe the FPS wouldn't be as bad then. I thought you were doing it for the entire playfield. I was wrong about 4 drawscreens in a game cycle being 12 FPS, it's actually 15 FPS. 5 drawscreens would be 12 FPS. Don't let this fact though deter you. Take your ideas and figure out how they would work in Batari if you end up using that. It's what I did with Princess Rescue. I had a lot of ideas for it, but found out how I was limited so I did the best I could and worked around them. You can still have the same layout that you do, just may have to back off on the detail and graphics. On the standard kernel, you only have 11 playfield rows to work with, so keep that in mind if your going to make a horizontal scrolling game. In Princess Rescue, I made them all even so I could do multiple colored blocks, which is what you are going to have to do. If they were all the same color (like in Zippy), then you can change the width of each row. That's why Zippy and PR have the look they do. The blocks in Zippy have different heights because I use the same color, but in Princess Rescue the blocks are all the same size because I wanted to use different colored blocks.

i tried reading the pr code but completely sucked. so this is impossible to do anyway due to the color vs width restriction. :C still fail. btw, the layout is a random one depicting all the possible blocks in one screen.

[Sprybug]

i tried reading the pr code but completely sucked. so this is impossible to do anyway due to the color vs width restriction. :C still fail. btw, the layout is a random one depicting all the possible blocks in one screen.

The PR code is pretty complex for Batari, and since you don't have any experience in programming, I don't expect you to understand one line of it. I know you said that even the Tinkernet video was confusing, but give it another try. Don't try to watch it all in one sitting and try to remember it all (and don't use his installer either, it's super old!). He does things one step at a time. When does one example. You do it and try to understand it. Then when it works and makes sense, move on to the next one in the video and then you do it, etc. I find that experience is the best way to learn! Sometimes I can read and read and read and don't really get it, and then once I do it, it all starts to come together. Like my career for example. When I started school, my animation and art skills were not good and I worked hard but still wasn't making progress, and then finally about 3/4 of the way through the course, it all started to come together, and after all those late nights working hard at it, it all started to work and now I've got a good career in animation working out for me. I don't expect you to figure things out right away. It's just gonna take some practice and a some growing pains before you might start to figure it out. Hate to have all this motivation and inspiration go out the window.