293 replies to this topic

[Opry99er]

Yea--- I have Air-Sea Battle. I've seen a ton of colors, but I thought we were talkin' 32 maybe with some pixel checkering to get more. I wasn't aware there were 256 though!!! You know, there is a cool language called BAtari BASIC. It's a BASIC dialect that compiles into Atari machine code.

[sometimes99er]

Opry99er, on Wed May 12, 2010 6:46 AM, said:

Yea--- I have Air-Sea Battle. I've seen a ton of colors, but I thought we were talkin' 32 maybe with some pixel checkering to get more. I wasn't aware there were 256 though!!! You know, there is a cool language called BAtari BASIC. It's a BASIC dialect that compiles into Atari machine code.

Hey, maybe some pixel checkering (AA55 ...) would make the TI come closer to the Atari Adventure ? Flipping color every frame can add some colors too. The maximum is 105, but some of them, like flipping between black and cyan, tend to overstrain your eyes.

Yes, Batari is very nice, and might have inspired Strawberry. AFAIR Batari is a compiler, and then you make the programs using any text editor. I was thinking of doing that too/instead.

[Opry99er]

I'll play with some checkering today---see what I can come up with.

[Opry99er]

Here's another representation. I used white instead of gray as the background and light yellow instead of dark yellow in the foreground. Still not the result I wanted. I tried a pixel checker, but it looked like crap. I'll post a pic of that later.

[GroovyBee]

Why don't you just update the graphics and take it from there?

[Opry99er]

With checkers to create a darker gray



Not exactly smooth looking, but the contrast is good. The key and arrow will be SPRITEs, so it will work fine in that regard... however, here--- the backgrounds wouldn't work with these items... so I left them out

[Opry99er]

I might go ahead and update the graphics, as you suggest. I am thinking we don't need to remain 100% true to the Atari version. Give me a few minutes... I'll have somethin for ya. =)

[Opry99er]

Here's just a little idea about how to update... Not sure if I like it, but it DOES make it look nicer. =)

[GroovyBee]

There is just waaaay too much brick for my liking.

[Opry99er]

Gotcha---- I'll update

[mimo]

aaagh that looks worse than the original (sorry)

[Opry99er]

here ya go. what about this one?

[Opry99er]

I could leave the brick JUST on the castle, and take the brick pattern off the walls surrounding the castle... Or forget the bricks altogether

Edited by Opry99er, Wed May 12, 2010 9:23 AM.

[unhuman]

Don't like the bricks. My eyes go nuts.

[Opry99er]

Cool, I'll work something else up. =) Sorry for hurting your eyes. =)

[GroovyBee]

I think a complete revamp of the graphics would be better using more colours too. The bricks are just making things worse .

[unhuman]

GroovyBee, on Wed May 12, 2010 9:27 AM, said:

I think a complete revamp of the graphics would be better using more colours too. The bricks are just making things worse .

Actually - I like the idea of bricks, but not that density... Perhaps bricks (partial) in some areas of the castle would look good - if that makes sense....

[S1500]

So what would be the logic for moving around the maps? I would probably get the character x-y coordinate(not sprite x-y coordinate), maybe do a call of a GCHAR function, then find out what color it is. If it's the background color, you can move through/around. If not, you are hitting a wall, and thus cannot.

The you need to check to see what direction off-screen are you going(N,E,S,W). If so, reset the sprite to be on the other side of the screen, determine which map to draw next, redraw the map, and you're good to go.

Maybe a two-dimensional array to have the overall "world" to work with? You move north, you go up a row in in the array (x-1,y), and the array holds the map pointer. The pointer could then point to which map(A-Z), and a routine would then draw said map. Another routine would be run to overlay the map with the items(bridge, etc), and then it's the player's turn.

Bridge location would be a set of coordinates in relation to the world, then maybe another set to be specifically where on the map tile it would reside.

Wow, you could pretty much make this game in Extended Basic.

[Opry99er]

This is a bit cartoonish, but I thought I'd give it a try. Not actually "NEW" graphics, just a way to alter this one a pinch. When I get some time, I'll start from scratch and come up with something wicked awesome cool.

[Opry99er]

Yea, it would be possible in XB, but screen draw time would take away from it. That's the issue. I could easily write an assembly routine to draw the screens quickly... but I think we should do this in assembly so we could have it on a cartridge. =)

[The Codex]

Pseudo 3D. Better, worse, or indifferent?

 pseudo3d.png   4.45K   9 downloads

[GroovyBee]

The Codex, on Wed May 12, 2010 10:11 AM, said:

Pseudo 3D. Better, worse, or indifferent?

Better! Personally I'd like to see more windows, walls, moss, bricks, grass, trees, plants the works . It depends how much you want it to look like the original.

[Opry99er]

I've got some ideas for music as well. A standard "adventuresque" dungeon tune for the main exploration theme, and something darker for the "Dark Maze" portions. Ill try to whip something up in XB and post it here.

[Opry99er]

I was kind of thinking "keep it as original as possible," but it seems like there's some interest in doing a bigtimr upgrade... I'd be happy to go all out, but it's up to the community.

[GroovyBee]

You could have the "purist mode" and the "big time mode". But if you were a true purist you'd be playing on the original 2600 hardware. I say take it and run with it and then see where it goes.