That seems interesting :) I can't wait for screenshots :)
I assume since you say everything that moves will be monochrome that there won't be scrolling, right?
My suggestion: Use the speed of Axe to your advantage and make the AI intelligent, or able to deliver a lot of fire.
Actually, shoot for both (pun intended).
sounds fun!
how are you going to manage 9*9 tiles?
I'm very interested to see how this progresses. I am a bit concerned about speed though, because Contra can have ALOT of objects on the screen at once.
I'm very interested to see how this progresses. I am a bit concerned about speed though, because Contra can have ALOT of objects on the screen at once.
YAY Contra for calculator, I used to play that in a browser NES emulator :)
sounds fun!
how are you going to manage 9*9 tiles?
I was wondering that too....x.x Ash's 12x12 tiles are actually masked 16x16 where the extra parts are transparent, but I don't think that'll be practical for this
i would recommend staying away from bitmap at all costs. I believe it has the corresponding speed of 200+ sprite displays, even at the smallest size since its a TiOS routine. I would recommend writing your own column filling routine for the scrolling. I can help you out there if you need it, i wrote one a while back and they can be a little tricky, although the fact that you are only scrolling in one direction makes it a lot easier ^^
(only one direction? Up and down now going to happen?)
And is 8 sprite height sufficient to port Contra?
What? o.O *Builderboy is confused*
What? o.O *Builderboy is confused*
The original Contra is 7 blocks vertically. I was thinking 9 pixels per block * 7 blocks = 63 rows of pixels, which would have filled the screen nicely. But I think I'll stick to 8x8 :-\
What? o.O *Builderboy is confused*
The original Contra is 7 blocks vertically. I was thinking 9 pixels per block * 7 blocks = 63 rows of pixels, which would have filled the screen nicely. But I think I'll stick to 8x8 :-\
You could just use the lower 56 pixels for the game (7 blocks * 8 pixels) and the remaining 9 pixels on the top for scenery like clouds.
Er, Deep Thought, Contra is 15 blocks high, not 7. The NES screen is 240 pixels high and NES tiles are 16x16.
EDIT: actually it's 14. Most tiles seems to be blocks of 4 16x16 tiles, but somewhere else in the game I saw such blocks that were one tile high only. If you really want to divide the map size by half, some parts might require modifications.
Good luck with this project!this. ;)
Yeah I recommend staying away from Bitmap too. Quigibo only added them for those who need to save space but don't care about speed.
Ah ok, thanks for confirming. For the half-tile platforms you could remove them indeed. I doubt they will matter much anyway. Good luck with this project!
Good luck with this project!this. ;)
so, how far are you into coding? or is this still in the planning stages?
This is what Quigibo's Bitmap command uses.Yeah I recommend staying away from Bitmap too. Quigibo only added them for those who need to save space but don't care about speed.
Also, there's a ROM call for that in assembly ;) that's probably another reason why
it drawns to the buffer AND updates the screen. I don't recommend :P
Idk if this has been mentioned, but...
will you add the Contra Code? ;D
I think a conceptual screenshot is in order ^^ Or maybe a real one :D
Oh I think he meant a fake screenshot, drawn in Paint or something, not a capture from the calc/program. Otherwise a pic of the calc and the game can do, I guess, as long as you resize it down :PIdk if this has been mentioned, but...
will you add the Contra Code? ;D
;)I think a conceptual screenshot is in order ^^ Or maybe a real one :D
Hmm, mind if I post a pic of the real calc? That's really the only way I can get shots right now since I don't have a cable anymore.
I think a conceptual screenshot is in order ^^ Or maybe a real one :D
I noticed that the right part of the screen seems to be lacking greyscale o.O Heh it looks awesome so far though ^^ Does the character seem to change shape in different positions?
@BB in some instances in the screenie the char aims his gun downward(or so it appears) and I think when the char appears more compressed he's supposed to be crouching(maybe?). The random non grayscale platform off to the side does look kinda odd tho.
You could maybe add a pixel on the side for the gun. I can't wait to see more updates on this. :)
Are the non-grayscale platforms to the right caused by bad WabbitEmu settings, by the way? Also what will you put on the empty parts of the screen?
Personally I like using horizontal commands :P But if redrawing speed isn't an issue, collision detection will be easier to deal with because the offset value is probably also easier to deal with using a redraw method
Ouch, I hope you can manage to keep it at decent speed. In the worst case, maybe you could ditch grayscale?
Yeah, they don't "get up" after jumping. That's just extra stuff, so I'll work on that after I get the engine stuff done.
And thanks for the screenie, DJ. I might change stuff and take the grayscale out...
Personally I like using horizontal commands :P But if redrawing speed isn't an issue, collision detection will be easier to deal with because the offset value is probably also easier to deal with using a redraw method
Well, no matter what, I have a portion of the tilemap (the portion on the screen) stored in an 70-byte array at L5 (it's 9x7 plus another column that gets scrolled in). It's really easy to work with, so redrawing/horizontal doesn't really matter at all. It's just a matter of which turns out to be faster (and which one looks better). I just tested redrawing every single frame (even without scrolling), and it's already pretty slow (even without enemies x.x), so that definitely won't work...
I don't have a screenshot, but
Update
Completely started over (again). It's now a lot better than before (several times faster, even with scrolling implemented). Bullets now work perfectly, and I'm adding the enemies right now. So basically, the engine is pretty much done :D
EDIT: Oh, yeah, and it's still full grayscale. And fixed all those bugs in the earlier screenshot too: the character lands upright (instead of staying in a ball), he doesn't stop in the middle of a platform if he falls there, and scrolling with bullets actually works.
Well as he said in his new post, (that one you quoted is from November) he changed the way things are drawn. Seeing as he mentions a huge speed increase, I wouldn't be surprised if this is what he is doing now.Personally I like using horizontal commands :P But if redrawing speed isn't an issue, collision detection will be easier to deal with because the offset value is probably also easier to deal with using a redraw method
Well, no matter what, I have a portion of the tilemap (the portion on the screen) stored in an 70-byte array at L5 (it's 9x7 plus another column that gets scrolled in). It's really easy to work with, so redrawing/horizontal doesn't really matter at all. It's just a matter of which turns out to be faster (and which one looks better). I just tested redrawing every single frame (even without scrolling), and it's already pretty slow (even without enemies x.x), so that definitely won't work...
What about using Horizontal to move the bulk of the image, then just drawing the new line that's shifted in?
Cool to hear. WIll it make it harder to draw enemies and bullets, though?
Well as he said in his new post, (that one you quoted is from November) he changed the way things are drawn. Seeing as he mentions a huge speed increase, I wouldn't be surprised if this is what he is doing now.
Well as he said in his new post, (that one you quoted is from November) he changed the way things are drawn. Seeing as he mentions a huge speed increase, I wouldn't be surprised if this is what he is doing now.Personally I like using horizontal commands :P But if redrawing speed isn't an issue, collision detection will be easier to deal with because the offset value is probably also easier to deal with using a redraw method
Well, no matter what, I have a portion of the tilemap (the portion on the screen) stored in an 70-byte array at L5 (it's 9x7 plus another column that gets scrolled in). It's really easy to work with, so redrawing/horizontal doesn't really matter at all. It's just a matter of which turns out to be faster (and which one looks better). I just tested redrawing every single frame (even without scrolling), and it's already pretty slow (even without enemies x.x), so that definitely won't work...
What about using Horizontal to move the bulk of the image, then just drawing the new line that's shifted in?
Yeah, that's pretty much what I'm doing, except that I wrote my own Horizontal routine to only move the stuff I want to move (the 9x7 map in the middle of the screen). So I don't have to redraw everything else, which is great.
Oh that's cool, less stuff to scroll means much faster. :D
Is it hard to scroll smoothly, though?
Oh that's cool, less stuff to scroll means much faster. :D
Is it hard to scroll smoothly, though?
Nope, still pretty smooth. I'll try to get a screenshot to post when school starts again :)
EDIT: And maybe a demo.
Ah nice, but I mean how do you handle drawing sprites outside the area without erasing everything around the map where stuff is drawn? I mean the sprite clipping and such things.
Oh that's cool, less stuff to scroll means much faster. :D
Is it hard to scroll smoothly, though?
Nope, still pretty smooth. I'll try to get a screenshot to post when school starts again :)
EDIT: And maybe a demo.
Nice! I can't wait for it, since I'm a Contra fan (web browser SNES emulator)
I'm putting everythhing off for a bit just in case someone knows a way to uncorrupt an archive.../me bangs head against the wall because another person neglected to make backups
Oh dear D: Thats horrible, no backups on the computer from when you made screenshots?
This sucks :/, I wish you had an easy way to regularly transfer files on the computer. I wonder if the stuff can be recovered? Someone might know how
When you perform a ROM dump with TiLP, does it includes the archive content like Virtual TI? If so, maybe someone could analyze the ROM data and grab your files?
I hope you don't kill this project, though...
Sounds like a quick recovery though, which is great!
That would be great. You should sticky the topic in the calc help section and also add other info about other ways to fix a calculator that crashed or froze.Sounds like a quick recovery though, which is great!
Yep, I can post a quick tutorial if anyone wants (in case anone else gets that issue).
That would be great. You should sticky the topic in the calc help section and also add other info about other ways to fix a calculator that crashed or froze.Sounds like a quick recovery though, which is great!
Yep, I can post a quick tutorial if anyone wants (in case anone else gets that issue).
Update
Still no screenshot, sorry :-\
I can get enemies to move around adn jump randomly, and now to add AI.
It's just over 3 KB for both source and exec, so I still have a lot of space to add all that other stuff, so I think the final version will include some of the classic Contra levels. It'll definitely support external levels, though.
Amnd I promise I'll get a demo up as soon as I can add this new stuff :D
Enemies randomly jumping? That's cool ;D
If custom levels are supported, you mean a level editor? I love those.
I'll get the demo to you soon, stupid tiConnect is acting up, so I had to reinstall it on a different computer.
wow, lots of progress since last time! This is going to me one of my all-time eagerly awaited games. ;D
/me puts pressure on Deep to finish it... :P
O.O that's a lot of source programs
Looks great.
Looks a bit flickery but overall very awesome! Will you have trouble seeing the character over the tiles?
Not much, but as promised:
Contra Pre-Alpha Demo v0.01 (4-11-11)
(http://clrhome.co.cc/projects/contra/screenshots/4-11-11.gif) (http://clrhome.co.cc/projects/contra/screenshots/)
Download (http://clrhome.co.cc/projects/contra/screenshots/4-11-11.8xp)
Maybe you could post something on TI-Freakware as well, as we don\'t want that it gets inactive.
tried it already. look great except for one thing: can the turret thingies die?
Great an Alpha version! Must try!
EDIT: Already tried it, it looks good, but we aren\'t supposed to be able to go back?
I don\'t think you are able to go back? I just downloaded it to my calc, and the greyscale and controls are superb, although I had a lot of difficulty seeing the character and the bullets over the textured backgrounds :( There were times when i didn\'t even know the enemy was shooting at me because I couldn\'t see anything. I\'m not sure how to fix this, right now you are using XOR sprites so that the sprites show up on black and white textures right? The only way I can think to make this work would be to use masked sprites with a white outline or something, but I don\'t know if that would work well :/
I tried the original game, and yeah we can\'t go back, and I had the same experience as Builderboy, finding me and my enemies is hard, but I guess that\'s part of the fun?
Quote from: ScoutI tried the original game, and yeah we can\'t go back, and I had the same experience as Builderboy, finding me and my enemies is hard, but I guess that\'s part of the fun?
Guess you could think of it like that :D
I was thinking more along the lines of making the character white with a black outline. It would be only a single more sprite per frame, it shouldn't slow down the game too significantly, and I think it would help with visibility tenfold. As for bullets however, drawing twice as many sprites for each bullet seems very excessive... maybe use Rectangles? For a rectangle of 3x3 with a white center, it draws faster than a single sprite would. It would have black edges no matter what, and a white center no matter what, so it would show up in all scenarios and be faster than a sprite (if a sprite is what you are using right now :P)
I was thinking more along the lines of making the character white with a black outline. It would be only a single more sprite per frame, it shouldn't slow down the game too significantly, and I think it would help with visibility tenfold.
As for bullets however, drawing twice as many sprites for each bullet seems very excessive... maybe use Rectangles? For a rectangle of 3x3 with a white center, it draws faster than a single sprite would. It would have black edges no matter what, and a white center no matter what, so it would show up in all scenarios and be faster than a sprite (if a sprite is what you are using right now :P)
It will make the game every so slightly slower (since you are drawing 1 extra sprite per frame) but as bullets are added it will lag less because bullets will be drawn faster. The main goal is visibility because so many people are having a hard time seeing anything.
Not much, but as promised:
Contra Pre-Alpha Demo v0.01 (4-11-11)
(http://clrhome.co.cc/projects/contra/screenshots/4-11-11.gif) (http://clrhome.co.cc/projects/contra/screenshots/)
Download (http://clrhome.co.cc/projects/contra/screenshots/4-11-11.8xp)
DISCUSS: http://ourl.ca/7770/196692#new
EDIT: can you kill enemies?
NICE!!!!!!!!!!!!! Even though you can't kill enemies and there are not very many :( GREAT JOB!!! ;D(http://www.omnimaga.org/Themes/default/images/gpbp_arrow_up.gif)
I think the opening shifts the title screen over 1 pixel too far -- I saw that on the very right was a white line with gray bits ;)
other than that, looks very seamless! Great work so far :)
Sourcecoder? Is it edited in Hex or by Image? Because if its by image you can just drag and drop the image into TiConnect and it will send :)
Not much, but as promised:
Contra Pre-Alpha Demo v0.01 (4-11-11)
(http://clrhome.co.cc/projects/contra/screenshots/4-11-11.gif) (http://clrhome.co.cc/projects/contra/screenshots/)
Download (http://clrhome.co.cc/projects/contra/screenshots/4-11-11.8xp)
DISCUSS: http://ourl.ca/7770/196692#new
Eh, it's already at the max speed moving two pixels each frame :P
Also, it seems SC does support the 96th column. Maybe Axe doesn't? I don't see why it wouldn't though...
Looks nice Deep THought! I'm glad this is alive again. :)
I agree about the character being hard to see over gray background, though. It should probably have an outline or change color depending of the background.
EDIT: and DT, if you're using TIOS pics, it only supports up to 95 pixels wide ;)
X=95 and Y=63 is the most bottom-right pixel, way in the corner. Remember it counts from zero ;)Eh, it's already at the max speed moving two pixels each frame :P
Also, it seems SC does support the 96th column. Maybe Axe doesn't? I don't see why it wouldn't though...
I have a problem with X=96 and Y=64 in Axe too.
Yep, and that's why I want to port it as close as possible :)
There's an online emulated version here: http://nintendo8.com/game/60/contra/
Yep, and that's why I want to port it as close as possible :)
There's an online emulated version here: http://nintendo8.com/game/60/contra/
No I don't need an emulator I have one (nester)
Yep, and that's why I want to port it as close as possible :)
There's an online emulated version here: http://nintendo8.com/game/60/contra/
cool I can't wait untill soldiers come in the game and a level editor and boss maker are made!!!
By the way Deep, shouldn't the entire screen become dark instantly on launch, with the title screen scrolling in afterward? Because in the original the screen was all black when it did.
How is it going adding the masking and outlines?
Oh right, I changed the links didn't I. I'll update them when I get home (can't edit posts from here).
This is temporarily on hold until I get my contest entry up and running.
DT, is the entire screen redrawn every frame? Cuz if it is, you can just apply horiz commands to saved greyscale buffers and redraw only the tiles you need to.I have an appvar to save the tilemap, so I don't have to redraw it every frame. Instead, I do this for each frame:
I agree about the main sprite, though. Also the bullets seems to go a bit off the game area to the left sometimes. (over the HUD)Yeah, that's true. Another thing I should fix. And here are some more updates from today: