jrok
-
Content Count
1,156 -
Joined
-
Last visited
-
Days Won
5
Posts posted by jrok
-
-
These are all nice. I've never been one who minded pressing up to jump, but these are a nice alternative.
The problem I had with the first demo was the inability to shoot while running.
I think the 2nd demo is my favorite.
While I like the idea of being able to sprint while running, it seems that when I go to jump a hole when running at normal pace, I may mess up because of the sprint which I'm forced to do. Precise jumping is difficult because of this. I do like the added ability to roll.
Thanks, Kevin!
The idea in the latest version is that you can't leap forward while running at a normal pace (although, you can jump straight up by just pressing up and pressing the fire button). The closest I can think of to these controls is Out of This World/ Another World.
-
Okay here is a updated version of the demo. I revised the controls as follows:
Jog: Joystick left or Joystick right
Sprint: Joystick up-left or Joystick up-right.
Duck: Joystick down, Joystick down-left or Joystick down-right.
Shoot: Fire button and...
- no Joystick
- Joystick down
- Joystick left
- Joystick right
Jump: Fire button and...
- Joystick up
- Joystick up-left
- Joystick up-right
Roll: Fire button and...
- Joystick down-left
- Joystick down-right
New demo screen: I did away with the 2-color "big sprite" and am using a single P1 to draw the player graphics now. I also revised the screen layout to fit in three platforms instead of two, and created a series of jumps of various difficulty (the top platform containing the most difficult jump; it is possible to make it, but you have to jump at the last possible second).
- no Joystick
-
Here is a version with the following changes:
1) Shoot while Running: Fire + Joystick left or Joystick right.
2) Hi-Speed Sprint: Joystick up-left or Joystick up-right
So the idea here is that the up diagonals give you a boost of speed while you're running towards your jump-goal. The thing I like about it is that it marks an obvious on-screen change between shooting and jumping modes, and that this change actually helps achieve the players goal (jumping over an enemy or across a gap) by giving his jump more horizontal momentum.
-
23,000 members, but it's like I'm talking to myself...
Geez, sorry no one got back to you quickly enough. Ripping off music is fun and easy!
1) Open the game in your favorite program (MS Word, MS Paint, Google Chrome, World of Warcraft, etc)
2) Search for the label, "CoolToonz4Free" and a bunch of musical notes.
3) Copy and paste it into your code (don't worry about where; pretty much anywhere will do)
4) Bake for 20 minutes at 325°
5) $$$ Sell game for Big Bucks! $$$
-
Very nice demo game!
I am sorry but for me "fire button to shoot/ press the joystick up to jump is just counter intuitive and feels unnatural".
Perhaps I have to get used to your new control system...
That's the point of the demo, though. Pressing up doesn't jump unless you also press the fire button.
-
Here is a version with the same controls, but that allows the player to shoot while running.
-
Since it seems you have to stand still to fire, how about this:
Jump: Fire + Joystick up, up-left, up-right, left, or right
That would be more intuitive to me.
Hmm, maybe. Or maybe it would be better to just let the player shoot while running. The only problem I see with fire + left/right to jump is that in the middle of a fight, you might jump when meaning to shoot. I'd prefer not to die from lack of shooting back.
-
I recall we had some conversations before about using the fire button to shoot versus using it to jump. The problem is that some game designs call for a lot of shooting and jumping. I agree with the general consensus that using "fire button to shoot/ press the joystick up to jump" is just counter intuitive and feels unnatural, so I started working on a way to use the fire button for both actions.
In this little demo, the controls are as follows:
Jog: Joystick left or Joystick right
Sprint: Joystick up-left or Joystick up-right.
Duck: Joystick down, Joystick down-left or Joystick down-right.
Shoot: Fire button and...
- no Joystick
- Joystick down
- Joystick left
- Joystick right
Jump: Fire button and...
- Joystick up
- Joystick up-left
- Joystick up-right
Roll: Fire button and...
- Joystick down-left
- Joystick down-right
So basically the idea is that whenever the up-switch is detected on the joystick, you are in "jumping mode," and when it's not detected you are in "shooting mode." So, you can also shoot in mid-air as long as you aren't pressing one of the "up" directions (up, up-left or up-right).
I think that the demo I threw together could potentially be Pitfall-esque gameplay... except of course that you can blast stuff!
If any of you guys get a chance to play around with it, I'd like some feedback on how comfortable this control setup is. It would be especially great if someone with an Atari joystick (either USB or real hardware) can let me know if it feels natural.
Thanks,
J
Latest version:
Note: See latest post in this thread for list of changes.
Older versions:
- no Joystick
-
Okay, so I do everything that looks right, and then when I try to compile the program, it hates one particular line no matter if it's not the same line, or whether I change the spots of the code.
Maybe it'd be easier if I told you an example.
Type in code, compile program, hates line 9. Put code in different spot, compile program, hates line 9 again. Try rewording code, compile program, etc.
I'm using Visual batari Basic on a Windows 7 computer.
Here's some code I've written so far. One thing I think it hates is the "pfcolors:" command, so I try not to use it.
playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XX.XX.XX.XX.XX.XX.XX.XX.XX.XX.XX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X.X.X.X.X.X.XX.X.XXX.X.X.X.X.X.X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXX...XXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end COLUBK = $00 COLUPF = $0E set missile0height = 5 missile0x = 50 missile0y = 50 draw_loop drawscreen goto draw_loop
Am I writing the code wrong? Help me please!
You need to indent your statements.
playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XX.XX.XX.XX.XX.XX.XX.XX.XX.XX.XX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X.X.X.X.X.X.XX.X.XXX.X.X.X.X.X.X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXX...XXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end COLUBK = $00 COLUPF = $0E set missile0height = 5 missile0x = 50 missile0y = 50 draw_loop drawscreen goto draw_loop
-
I had/have a game about Zombies in the works called "Game of The Living Dead". The name is a take on the movie Night of The Living Dead. I didn't get very far, probably because I haven't programmed in awhile. I also haven't done a game with more than one enemy updating at a time.
The game play is like the Activision game Oink! kind of. You start at the bottom and have to barricade your house in. The zombies come down the screen and try to break in your house to eat your brains.
I like this idea. Any chance of it becoming a reality?
-B
I was actually working on something similar awhile back (though I don't think I posted any progress on AA). Instead of heading down the screen, the zombies enter on the right and move towards the player who is shooting at them from the left. Between the zombies and the player is a wall that the zombies gradually chew through when they make contact with it. There's enough vertical separation to get up to 12 zombies on the screen without flicker. Here's a quickie demo (minus the shooting player).
-
-
To help myself and others, I'm adding a few things to the Superchip RAM section of the bB page. The page says the following about Superchip RAM variables:
These special variables cannot be used for fixed-point math, 16-bit multiplication or division, as the counter variable in for-next loops, or any functionality that requires dimming a value to a user variable. There may be other limitations as well.That's helpful, but it would also help to have a list of what we are allowed to do with them.
You also can't use them as counters for "on...goto/gosub" commands.
-
Thanks. I see that if we leave the screen at the default resolution, the visible screen is r/w080 through r/w123 and the hidden row is r/w124 through r/w127.
Yep. The last four are the hidden row, and so can be used freely with no trouble.
Problem is this: 24 * 4 = 96 and 128 - 96 = 32. That would be w/r032 through w/r127, not the w/r033 that you posted. Is your w/r033 incorrect?
Sorry, that was a typo on my part. It would be r032-r127.
I'd test it myself, but when I made a simple test program using "const pfres=24" I get this error:
--- Unresolved Symbol List kernelmacrodef 0000 ???? (R ) pfwidth 0000 ???? (R )
Can you tell if anything is wrong with my test code:
set romsize 16kSC const pfres=24 ...
I didn't have any trouble compiling it, so I'm not sure what the problem could be.
-
I'm not sure whether you mean the memory inside the Superchip, or the zero-page addresses that are used when the playfield gets moved to the Superchip, or both. If both, I would include the playfield RAM addresses that are inside the Superchip.I mean something that looks like the following, except with the Superchip changes:
Standard Kernel Memory Map $80 player0x $81 player1x $82 player0colorstore missile0x $83 missile1x $84 ballx $85 player0y objecty $86 player1y $87 player1color missile1height $88 missile1y $89 bally $8a player0pointer player0pointerlo $8b player0pointerhi $8c player1pointer player1pointerlo $8d player1pointerhi $8e player0height $8f player1height $90 player0color currentpaddle missile0height $91 paddle missile0y $92 ballheight $93 score $94 $95 $96 scorepointers $97 $98 $99 $9a $9b $9c temp1 $9d temp2 $9e temp3 $9f temp4 $a0 temp5 $a1 temp6 $a2 rand $a3 scorecolor $a4 var0 Playfield Variables $a5 var1 $a6 var2 There are 4 variables for each row. $a7 var3 (8 bits x 4 = 32) $a8 var4 $a9 var5 $aa var6 $ab var7 $ac var8 $ad var9 $ae var10 $af var11 $b0 var12 $b1 var13 $b2 var14 $b3 var15 $b4 var16 $b5 var17 $b6 var18 $b7 var19 $b8 var20 $b9 var21 $ba var22 $bb var23 $bc var24 $bd var25 $be var26 $bf var27 $c0 var28 $c1 var29 $c2 var30 $c3 var31 $c4 var32 $c5 var33 $c6 var34 $c7 var35 $c8 var36 $c9 var37 $ca var38 $cb var39 $cc var40 $cd var41 $ce var42 $cf var43 $d0 var44 $d1 var45 $d2 var46 $d3 var47 $d4 temp7 $d5 playfieldpos $d6 A a $d7 B b $d8 C c $d9 d D $da E e $db F f $dc G g $dd H h $de I i $df J j $e0 K k $e1 L l $e2 M m $e3 N n $e4 O o $e5 P p $e6 Q q $e7 R r $e8 S s $e9 T t $ea U u $eb V v $ec W w $ed X x $ee Y y $ef Z z $f0 pfheighttable pfcolortable aux1 $f1 aux2 $f2 lifepointer aux3 pfscore1 $f3 aux4 pfscore2 lives $f4 aux5 pfscorecolor lifecolor $f5 statusbarlength aux6 $f6 stack1 $f7 stack2 $f8 stack3 $f9 stack4 $fa [reserved for the stack] $fb [reserved for the stack] $fc [reserved for the stack] $fd [reserved for the stack] $fe [reserved for the stack] $ff [reserved for the stack]Doesn't some of that change when we use SC?
I believe all of the addresses are the same as in the standard kernel, with the added r/w addresses I gave you above (from superchip.h).
You also might want to note that var0-var47 are not being used to store the playfield when the superchip option is enabled, since this is now stored in superchip RAM. Those variables are free for general use, as are any of the additional w/r addresses that aren't being used to store the playfield. The amount of free r/w RAM available is dependent on your playfield resolution. For instance, a 32 pfres will use all SC variables w/r000 - w/r127 whereas a 24 pfres will only use w/r033- w/r127, etc.
-
The bB page has a Standard Kernel Memory Map and a Multisprite Kernel Memory Map, so does it also need a Superchip Memory Map? If it does, has anyone made one that I can put on the page?
Thanks.
write_RAM = $F000 wRAM = $F000 w000 = $F000 w001 = $F001 w002 = $F002 w003 = $F003 w004 = $F004 w005 = $F005 w006 = $F006 w007 = $F007 w008 = $F008 w009 = $F009 w010 = $F00A w011 = $F00B w012 = $F00C w013 = $F00D w014 = $F00E w015 = $F00F w016 = $F010 w017 = $F011 w018 = $F012 w019 = $F013 w020 = $F014 w021 = $F015 w022 = $F016 w023 = $F017 w024 = $F018 w025 = $F019 w026 = $F01A w027 = $F01B w028 = $F01C w029 = $F01D w030 = $F01E w031 = $F01F w032 = $F020 w033 = $F021 w034 = $F022 w035 = $F023 w036 = $F024 w037 = $F025 w038 = $F026 w039 = $F027 w040 = $F028 w041 = $F029 w042 = $F02A w043 = $F02B w044 = $F02C w045 = $F02D w046 = $F02E w047 = $F02F w048 = $F030 w049 = $F031 w050 = $F032 w051 = $F033 w052 = $F034 w053 = $F035 w054 = $F036 w055 = $F037 w056 = $F038 w057 = $F039 w058 = $F03A w059 = $F03B w060 = $F03C w061 = $F03D w062 = $F03E w063 = $F03F w064 = $F040 w065 = $F041 w066 = $F042 w067 = $F043 w068 = $F044 w069 = $F045 w070 = $F046 w071 = $F047 w072 = $F048 w073 = $F049 w074 = $F04A w075 = $F04B w076 = $F04C w077 = $F04D w078 = $F04E w079 = $F04F w080 = $F050 w081 = $F051 w082 = $F052 w083 = $F053 w084 = $F054 w085 = $F055 w086 = $F056 w087 = $F057 w088 = $F058 w089 = $F059 w090 = $F05A w091 = $F05B w092 = $F05C w093 = $F05D w094 = $F05E w095 = $F05F w096 = $F060 w097 = $F061 w098 = $F062 w099 = $F063 w100 = $F064 w101 = $F065 w102 = $F066 w103 = $F067 w104 = $F068 w105 = $F069 w106 = $F06A w107 = $F06B w108 = $F06C w109 = $F06D w110 = $F06E w111 = $F06F w112 = $F070 w113 = $F071 w114 = $F072 w115 = $F073 w116 = $F074 w117 = $F075 w118 = $F076 w119 = $F077 w120 = $F078 w121 = $F079 w122 = $F07A w123 = $F07B w124 = $F07C w125 = $F07D w126 = $F07E w127 = $F07F read_RAM = $F080 rRAM = $F080 r000 = $F080 r001 = $F081 r002 = $F082 r003 = $F083 r004 = $F084 r005 = $F085 r006 = $F086 r007 = $F087 r008 = $F088 r009 = $F089 r010 = $F08A r011 = $F08B r012 = $F08C r013 = $F08D r014 = $F08E r015 = $F08F r016 = $F090 r017 = $F091 r018 = $F092 r019 = $F093 r020 = $F094 r021 = $F095 r022 = $F096 r023 = $F097 r024 = $F098 r025 = $F099 r026 = $F09A r027 = $F09B r028 = $F09C r029 = $F09D r030 = $F09E r031 = $F09F r032 = $F0A0 r033 = $F0A1 r034 = $F0A2 r035 = $F0A3 r036 = $F0A4 r037 = $F0A5 r038 = $F0A6 r039 = $F0A7 r040 = $F0A8 r041 = $F0A9 r042 = $F0AA r043 = $F0AB r044 = $F0AC r045 = $F0AD r046 = $F0AE r047 = $F0AF r048 = $F0B0 r049 = $F0B1 r050 = $F0B2 r051 = $F0B3 r052 = $F0B4 r053 = $F0B5 r054 = $F0B6 r055 = $F0B7 r056 = $F0B8 r057 = $F0B9 r058 = $F0BA r059 = $F0BB r060 = $F0BC r061 = $F0BD r062 = $F0BE r063 = $F0BF r064 = $F0C0 r065 = $F0C1 r066 = $F0C2 r067 = $F0C3 r068 = $F0C4 r069 = $F0C5 r070 = $F0C6 r071 = $F0C7 r072 = $F0C8 r073 = $F0C9 r074 = $F0CA r075 = $F0CB r076 = $F0CC r077 = $F0CD r078 = $F0CE r079 = $F0CF r080 = $F0D0 r081 = $F0D1 r082 = $F0D2 r083 = $F0D3 r084 = $F0D4 r085 = $F0D5 r086 = $F0D6 r087 = $F0D7 r088 = $F0D8 r089 = $F0D9 r090 = $F0DA r091 = $F0DB r092 = $F0DC r093 = $F0DD r094 = $F0DE r095 = $F0DF r096 = $F0E0 r097 = $F0E1 r098 = $F0E2 r099 = $F0E3 r100 = $F0E4 r101 = $F0E5 r102 = $F0E6 r103 = $F0E7 r104 = $F0E8 r105 = $F0E9 r106 = $F0EA r107 = $F0EB r108 = $F0EC r109 = $F0ED r110 = $F0EE r111 = $F0EF r112 = $F0F0 r113 = $F0F1 r114 = $F0F2 r115 = $F0F3 r116 = $F0F4 r117 = $F0F5 r118 = $F0F6 r119 = $F0F7 r120 = $F0F8 r121 = $F0F9 r122 = $F0FA r123 = $F0FB r124 = $F0FC r125 = $F0FD r126 = $F0FE r127 = $F0FF
-
Okay here is a reworked "Circus Galacticus" that includes many of the same concepts and controls from "Redshirts." Use the select switch at the character selection screen to select a different gladiator. The gladiators begin with different balances of speed versus armor, and will ultimately vary in weapon range as well.
I've put in 9 very basic kill-or-be-killed levels, after which the game will simply reset. After a you kill or die, press the fire button after a few seconds to either move on to the last level (if you won) or return to the Title Screen (if you lost).
Cheers!
J
I hate to see Red Shirts abandoned BUT I love this new Circus Galacticus. My favorite build so far.
Wp
Thanks slim. I'm not abandoning the other game, though. I just think it needs a bit more thought, and I'd rather use this engine for the gladiator game.
-
Okay here is a reworked "Circus Galacticus" that includes many of the same concepts and controls from "Redshirts." Use the select switch at the character selection screen to select a different gladiator. The gladiators begin with different balances of speed versus armor, and will ultimately vary in weapon range as well.
I've put in 9 very basic kill-or-be-killed levels, after which the game will simply reset. After a you kill or die, press the fire button after a few seconds to either move on to the last level (if you won) or return to the Title Screen (if you lost).
Cheers!
J
-
This is without a doubt one of the most fun Atari games I have played all year
Can't wait to see it progress! I have been playing it everyday after work and I love the latest build.
Wp
Thanks Slim.
Although lately I've been giving it some thought, and I'm now thinking of maybe taking taking the work I've put into this and transferring it back over to Circus Galacticus. The run-gun-and-roll style just seems more appropriate for an enclosed arena, and now that I'm not using the playfield for weapon fire it's relieved a lot of problems with the engine.
I do like the idea of multiple player characters, so I reworked that into a "Character Selection" Screen, where different characters have different strengths, which can be slightly upgraded over the course of the game.
I still do like the "Redshirts" concept, though, so I'll save that for another game.
Cheers,
J
-
Also, I don't mind that the tentacle doesn't show up very often, as long as it will show up more and more often the further you get in the game.I can do that if I can get more variables.
Are you using missile1x for anything? With the colored player1, you can't use missile1height and missile1y for anything, but you can use missile1x. Also, it seems like you are using pfscore, but not using the second scorebar (pfscore2), so you could reassign that address to something else (if you haven't already)
I'm using the plain old 32 x 11 playfield. I haven't messed with Superchip RAM that much yet. I wonder how hard it would be to convert it? It would be nice to have more variables.
Well, there shouldn't be any problem in converting it. Just define the superchip kernel option you'll immediately have a ton of additional variables available to you. Of course I understand wanting to take on the challenge of doing it without that.
Really, though, it might be nice in general to add in a few critters that you can actually shoot and destroy to counterbalance the Wrothopod guys.
If I can get more variables, you never know what creatures might show up (or randomly pop out from behind a piece of seaweed when you shoot it).
Even without the superchip, you might be able to squeeze in some more variables. If you pop open 2600basic.h, you might be surprised to find several variables that you can substitute with constants. I did a lot of that when I was working on "Charge." For example, if you aren't planning on changing "scorecolor", you can define that as a constant value in 2600basic.h, and then define that address ($A3) for something else... such as "crab_anger_level."
Old
scorecolor = $A3
New
scorecolor = #14 crab_anger_level = $A3
Either way, good luck, RT! It looks like a great game.
J
-
Great game! Cool graphics, too... love the Wrothopod guys
Great concept and execution, and very polished. Also, I don't mind that the tentacle doesn't show up very often, as long as it will show up more and more often the further you get in the game.Now, let's talk about that giant laser crab...
I'm out of variables, so I won't be able to add a giant crab that shoots lasers out of its eyes or anything like that.What is your playfield resolution? Unless it is 32, and unless you are doing something tricky like storing player data in the RAM, you will definitely have memory free in the your Superchip RAM. Maybe plenty of memory. For example, in the game I'm working on I have a resolution of 24. In addition to var0-var47, I'm using w000-w032 (and their corresponding read addresses) to store 16 rows of shape and color for player1. Also, I'm using the last four address of SC (w124-w127) to store a few more things.
Anyway, if it turns out you didn't use this stuff, I demand my crab!
Really, though, it might be nice in general to add in a few critters that you can actually shoot and destroy to counterbalance the Wrothopod guys. -
2
-
-
This game keeps getting better and better. The whole concept of a game based on characters whose only purpose is to die is pretty fun in and of itself
Thanks! Yeah, I am going to try to expand on that concept along the way and integrate it into the scoring system. Particularly painful, awesome or hilarious deaths will earn you bonus points.
Haven't had a chance to play too much yet, but one minor issue I noticed is that the characters have a tendency to overlap some of the square obstacles. Especially if you do a barrel roll move too close to one. I was even able to barrel roll and walk right through some of them, or even walk around inside them (see attached pic). It doesn't really cause any functional issues, however. Just thought I'd point it out.
It's a bug. It happens to me sometimes too, although I guess not as often as it's happening to you. I had to try really hard to get it to happen just now, and I'm still not sure how to consistently replicate the bug. I think the main problem is with the fractional movement of the player sprite and the way I'm dividing it to find the player's PF position. I'll squash it eventually (I hope).
Also, there seems to be a score field at the bottom, but no matter what it remains "000038". If this is not active yet, or if it has some other purpose I have overlooked, please disregard this.
I have the score disabled for now. It's basically just showing the decimal color of the background (I have background switching disabled for now, too... I needed the RAM! Hahah).
Will keep playing and let you know if I find any other bugs, etc.
Thanks, Brian!
-
Okay, I've done a bit more work here. There are two kinds of rooms, now.
The first kind is natural terrain, where the playfield obstacles are a slightly darker color of the background, with some trees or grass added for decoration. I'll eventually add some functions to these decorative items (perhaps the trees can function as a way to hide from the enemy or vice versa?) but for now they are just static elements.
The second kind of room is a "machine" room. I guess these can be thought of as alien mini-bases/encampments. In machine rooms, the playfield obstacles are grey, and emit various kinds of beams that effect you in different ways.
-
Red beams - These kill you instantly when you touch them.
-
Green beams - There are two of these in the room. When you touch one, you are instantly teleported to the other one.
-
Purple beams - Ultimately these will cause a random (and usually very strange) effect, but for now they, uh, give you a drastic makeover.
For now, the enemies are unaffected by the beams, but that will change. Ultimately, I'll add a trigger device to some of the rooms (probably using the ball object), so that the player can flip the rays on and off while the baddies are walking under them, and add some additional smarts to the enemies so they can avoid the beams when they are on, and occasionally target the triggers when you are standing under a beam that's off.
On a side note, I've basically used up all of my RAM now, so I'm thinking of reducing the playfield resolution to free up some superchip RAM. I don't think this should affect much, since the playfields are already quite blocky.
Cheers guys,
J
-
Red beams - These kill you instantly when you touch them.
-
A tune isn't required, but it might be cool to have some kind of sound effect. I'm thinking along the lines of how a lot of arcade games do for their attract mode.
It doesn't have to be overly in-yer-face - a single note or noise played a few times with decaying volume to simulate echo, or a low-volume phasing effect.
+1. Almost none of the arcade classics I loved had music in either attract mode or during play. Or, if they did have some music, it wouldn't be a repeating loop, but just little incidental tunes here and there (Donkey Kong, for instance).
Continuous title screen music might be nice for polish, but if there's background music in the game itself, it:
1)better be a very groovy tune and
2)shouldn't replace in-game sound effects.
-
Did a quick test and basically every background with a LUM of 0* was best with regards to flicker and distinction between the red shirt/black slacks
* for black a LUM of 2 was best for the obvious reason.
Interesting. So I guess the best idea would be to go with lo-LUM backgrounds/ hi-LUM sprites? Maybe the pants could go hi-LUM red instead of black to compensate?
*EDIT*
Quick followup: If you run the game on Stella 3.x with the Game Properties set to 77 Phosphor blend, is it comparable to what you see on a real Atari in terms of color contrast?
Thanks again,
J
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Shoot and Jump
in batari Basic
Posted · Edited by jrok
Thanks, Piggles.
What would be really cool is if we could run multiple batari display kernels. With one kernel running the display for each third of the screen, each floor could contain two flicker-free sprites (or 4 30hz ones). I think a fairly cool action-adventure game could be accomplished in such a framework.