SeaGtGruff

It looks like there are web sites where you can do free text-to-speech conversions, but attached is a sample I made in WavePad. I also used WavePad to modify the voice a bit, and reduced the sample rate and sample size to keep the file small. Stupid human You couldn't hit the side of a barn.wav

Sort of off-topic from the title of this thread, but still in the "spirit" of criticizing the Xbox One: http://www.armytimes.com/article/20130614/OFFDUTY02/306140030/New-Xbox-sin-against-all-service-members-

Yes, there are programs that can do text-to-speech. If the development tool you're using (I'm not familiar with GameMaker) doesn't have some kind of text-to-speech function, you can download a program to do that and save the speech as a WAV file or other audio file type. I don't know what all is out there to choose from, but WavePad from NCH will let you type in text and create synthesized speech, then save it to a file. You can download WavePad for free, but I think maybe the text-to-speech tool will get disabled after the trial period is up. If that's the case and you don't want to buy it, I do have the master's version of WavePad so I could create the speech synthesis files for you if you need.

Which game console or computer would this be programmed for? Edit: Okay, you said "just PC" in your post, so I guess it's a computer with a modern OS (Windows, Mac, Unix, etc.). If that's the case, I'd think you should be able to just record brief messages and save or convert them to WAV files or other audio file formats, then play a given file in your game when appropriate. Edit #2: I guess maybe we need to know what *language* you're going to be programming in. I'd think most modern languages should have built-in functions or established practices for playing sound files.

If I didn't say so already, I was eventually able to validate my Steam account. They said they were having some sort of issues over the weekend. I'd just wanted to vent some steam because it really bugs me when, for example, a web site says they just sent you an email with a link to reset your password but no email ever comes, no matter how long you wait or how many times you request that another email be sent. That has happened to me countless times-- and I always check my spam box to make sure it didn't go there. It just really bugs me. If a site has temporarily gone caca such that they can't send a password reset email, or validation email, etc., then they should at least change their message to say "we're currently experiencing technical difficulties and can't send you an email right now, please try again later."

In defense of today's game programmers, today's games are much more complex (much more *everything*) than yesteryear's games. Then again, to quote Scotty in Star Trek III: The Search for Spock, "the more they overtech the plumbing, the easier it is to stop up the drain."

Why don't you just use pfpixel temp1 temp2 flip ?

After I posted my rant, I started up Steam again-- still getting the message asking me to validate my email-- and while playing with options discovered that I can tell Steam whether or not I want it to automatically keep Skyrim updated. Hmm, that might help with the constant updating-- which sounds like a great thing, except it gets annoying when you have to wait as long as 5 minutes for your game to sync each time you want to play it (even if you haven't played it since the last time you played it so it should still be in sync). And then when you quit your game it has to sync again. Anyway, I ran an integrity check on my Skyrim files and was told that 1 file didn't pass the muster and would be reacquired (no word on when that would happen). I waited a while and ran the check again but got the same message. Finally it started updating Skyrim (I may even have had to shut down Steam and restart it-- I forget). So eventually I was able to play Skyrim again. I made it through the quest-- for like the 5th time-- and this time it didn't crash as soon as the quest ended (I think that's the point at which it finally does a new autosave). So I'm done with that quest again. Still no response from Steam Support aside from the automated acknowledgement that they received my trouble ticket, but the annoying banner asking me to validate my email address has gone away, so maybe they flagged it as validated and figured they didn't want to tell me they fixed it.

I haven't played Skyrim in forever, and I usually exit Steam after rebooting my computer because it slows things down whenever it decides it needs to sync my game or check for and apply updates. And when I do play Skyrim I usually play it offline because I have no interest in playing online (and it slows things down because it wants to sync all the freaking time). So I start Steam tonight to play Skyrim a bit-- even though I'm currently stuck on the stupid Vaermina quest or whatever. I've completed that quest before, I started playing a new game and now I've decided to do that quest again-- except when I get to the end of the quest Skyrim crashes, every single time, and I have to go through the stupid dreamwalking all over again because IT WON'T LET YOU SAVE THE GAME ALONG THE WAY. So Steam starts up and asks me, is [email protected] still your email address? Yes, it is. Please validate your email address. OK, I click "Next" to have them send me an email with a validation link. Nothing. I wait a while. Still no email. I do it all again. Still nothing. And no, it isn't going into my spam box-- my spam box is completely empty. So I go to Steam Support. Um, I have to create a Steam Support account just to contact them. OK, so I create a Steam Support account. They send me an email with a validation-- funny how they can send one for THAT-- and I validate my email address so they'll let me contact them. I fill out the support ticket, and instead of just letting me type my question or issue I have to select the appropriate category, sub-category, sub-sub-category, and sub-sub-sub-category. As soon as I select the one about "validation email not received," they pop up a big message telling me I need to supply additional information to confirm my account. To hell with that, I'm not giving them anything. I don't ever buy anything online from them, I already paid for Skyrim ages ago. So I sent my message as is. And surprise, surprise, I get an email confirming that they received my question. So why can't they send me the stupid email with the link to validate the email address on my Steam account? I smell a scam. Meanwhile, I'm going back to playing Skyrim offline like I always do-- except it keeps crashing. I don't really care whether or not they ever validate the email address on my account, as long as they STOP ASKING ME TO VALIDATE IT. Rant mode off. [ROM]Ahhhh, I feel so much better![/ROM]

Yes, the Stella Programmer's Guide has perpetuated the incorrect usage of "overscan." It is the bible of the Atari 2600 programming universe and we must never go against it, even when it's wrong. That is not because it must never be contradicted, but rather because its influence is so all-pervasive that any attempts to go against it are doomed to fail before they're even begun. As for "front porch" and "back porch," they are used in connection with both the horizontal and vertical timings: The horizontal front porch is the horizontal blanking period that precedes the horizontal sync. The horizontal back porch is the horizontal blanking period that follows the horizontal sync. If the video signal includes a color burst signal, the portion of the horizontal back porch between the end of horizontal sync and the beginning of color burst is called the breezeway. In those cases some people appear to define the horizontal back porch as the horizontal blanking period that follows the color burst. The vertical front porch is the vertical blanking period that precedes the vertical sync. The vertical back porch is the vertical blanking period that follows the vertical sync. These terms are sometimes shortened by dropping the "horizontal" or "vertical" qualifiers when their meanings are clear from the context.

Hmm, I see what you mean about multiple ifs per loop, but hopefully it isn't a problem. Perhaps the manner in which people use a joystick helps negate any potential issues with bouncing? People tend to push on them pretty hard, and to mash the fire button pretty hard. I do know what you mean about the incorrect usage of a term driving you nuts. It bugs me the way Atari 2600 programmers use the term "overscan," but I know they aren't going to change, so I decided to shut up about it. As far as "debounce," I've been a major offender, and now that I realize it refers to something different than what I'd thought, I'll try to figure out something else to call it. "Edge detect the fire button" sounds kind of strange compared to "debounce the fire button."

I guess I'm guilty of perpetuating the incorrect usage of debounce. IIRC I picked up the term and its incorrect usage a few decades ago from a book about programming for the Atari 800. It certainly wouldn't be the first time that an author writing about Atari computers or game consoles had misused a term-- a good example would be the widespread misuse of the term "overscan" among Atari programmers to refer to the lines of vertical blanking at the bottom of a game screen. I see what you mean about debouncing an iffy connection versus edge detection in a signal, bogax, but as I now understand the term I guess debouncing proper isn't necessary when reading the joysticks, fire buttons, console switches, etc., since the're usually being read only once per frame. I presume that any bouncing in the signal before a steady connection is made would most likely occur (on average) sometime between the two reads, while the display is being drawn, such that by the time you read the stick/button/switch during the vertical blanking period a steady connection has already been made. On the other hand, an edge detection routine-- or whatever we should properly call it-- is definitely necessary in some cases, to prevent the program from responding more times than intended when the user pushes the stick in a certain direction, presses the fire button, presses one of the console switches, etc.

Thanks for mentioning that! I keep running into compile issues where the only way I can make a program compile is to either split some logic into nested ifs (such as "if a = 1 then if b = 2 then ..." instead of "if a = 1 && b = 2 then ..."), or split a nested if into separate lines, or some other type of revision in the logic. For the record, the version of 2600basic.exe that I've been using is dated 07/28/2011 at 12:32AM. I'll try the files you've linked to. I probably never applied them because the OS on my desktop computer is 32-bit, not 64-bit.

Even after I fixed that error the compiler kept crashing until I split the following line into two separate lines: Before (crashes the compiler): if h > 0 then AUDV0 = 8 : AUDC0 = 6 : AUDF0 = 1 : h = h - 1 : if h = 0 then AUDV0 = 0 After (compiles okay): if h > 0 then AUDV0 = 8 : AUDC0 = 6 : AUDF0 = 1 : h = h - 1 if h = 0 then AUDV0 = 0

When I try to compile it, I get a compile error on this line: if collision(player0,player1) then score = score + 10 : player1x = 255 : player1y = 255 : h + 10 The error is because you say "h + 10" without setting anything equal to it-- I'm guessing you meant to say "h = h + 10"?

batari Basic's pfscroll statement will let you scroll the entire playfield horizontally or vertically. With vertical scrolling you use the last playfield row (which is normally hidden behind the score) to move a new row of playfield data onto the screen as an old row of playfield data is being scrolled off the opposite edge of the screen. With horizontal scrolling you have to use pfpixel to draw a new column of playfield data on the screen as an old column of playfield data is being scrolled off the opposite edge of the screen. If you want to scroll just a row or two of playfield pixels, or scroll some rows in one direction but other rows in the other direction, or scroll different rows at different speeds, the pfhscroll function I posted will let you do that: http://atariage.com/forums/topic/201378-horizontal-scrolling-help/?do=findComment&comment=2576409 If you want to scroll just a column or two of playfield pixels, there's no existing routine or function that I know of for doing that, but it should be fairly easy (and reasonably fast?) to use a combination of pfread and pfpixel in a loop to shift the playfield pixels for a given column up or down.

There are places in your code where it looks like some things might not have been indented, means they start at the very beginning of the line when they need to have at least 1 space in front of them. Line labels and equates need to start at the very beginning of a line, but almost everything else needs to be indented or else the compiler/assembler will think it's supposed to be a label. this is indented this is not indented Note that the forum software likes to eat leading spaces. I'm not sure if it eats leading tabs. It's possible that your code was indented correctly but the forum software removed the leading spaces when you posted your code.

Actually, I guess in my example, the player will still "levitate" if he/she keeps pressing the fire button, so you'd probably want to add debounce logic for the fire button.

Add a timer/frame counter. Each time you call drawscreen, increment the timer afterward, then check the timer's value for whatever value you're interested in (in this case, 1 second would be 60 frames). Another approach is to set the timer to the desired value (60) and then decrement it instead of incrementing it. If you want the timer to update only when something specific happens-- like pressing the fire button-- then either set a flag/bit variable to indicate whether or not the timer should be updated, or (if feasible) incorporate the flag into the timer itself. The following example sets and decrements a timer, without needing a separate flag: dim jump_timer = a jump_timer = 0 loop rem * the following nested ifs will start the jump timer, but only if it isn't already started rem * (necessary to keep the player from "levitating" by keeping the fire button held down) if joy0fire then if jump_timer = 0 then jump_timer = 60 if jump_timer = 0 then player0y = 64 else player0y = 54 drawscreen if jump_timer <> 0 then jump_timer = jump_timer = jump_timer - 1 goto loop

Awesome! Thank you! I must say, some of the results are a lot different than I was expecting. But it's nice to know the SECAM 2600 is capable of producing more than just 8 colors.

It would be great If you (or any others with a SECAM 2600 and programmable cart) could post screenshots from the attached program. A screenshot from Stella is shown below, but from what you're saying it is expected to look different on an actual SECAM system? I guess that makes sense since SECAM alternates on each line-- as PAL does but in a different manner. I had to redo my test program because of that. Each square of color is an intersection of 8 columns of color with 8 rows of color, but the squares that look the same on Stella (e.g., blue alternated with black) are flipped around to show all 64 possible combinations. SECAM_colors.bas.bin

Do you have a programmable cartridge, like a Harmony or Krokodile or Cuttle Cart? If you do, I'd like to send you a program that displays all 8 SECAM colors and all 28 two-color combinations so you can take a screenshot of it for me.

One way to increase difficulty is-- as you mentioned-- making things run faster. The easiest way to do that is to just increase the rate of motion, such as player0x = player0x + 2 instead of player0x = player0x + 1 But that can make the increase too dramatic-- literally twice as fast. It would be better to use fixed-point variables with the x and y position variables so you can increase the rate of motion more gradually. Another way to increase difficulty as the game progresses is to introduce obstacles that either get in the way of letting the player accomplish the game's goal, or antagonists that actively attack the player or otherwise make the gameplay more complicated. For example, if your game involves cleaning an apartment, you might start displaying more trash or whatever on the game screen at the same time, so the player has more work to do-- or start adding obstacles like chairs or a sofa or a table that the player must get around to reach all the trash, or add a kid that goes around making more messes while the player is trying to clean, or a small dog that keeps getting loose and interfering such that the player has to take a moment to get the dog and re-tie its leash to the doorknob or whatever to keep it out of the way. Another way to increase difficulty is to have each level be timed, so that you must try to complete the goal before the timer runs out. If you don't finish-- no sweat, you still get points for what you did do. But if you manage to clear the level before the timer expires, maybe you get extra points for completing the level, plus some additional extra points for every second of time remaining, etc. As the player gets into higher levels, the time allowed to complete each game might get progressively shorter.

That looks questionable to me. Shouldn't player1 have separate variables of its own in player1x.a and player1y.b instead of using player0's variables (I'm referring to the a and b)?

When you want to have multiple screens in your program, you draw the playfield, draw and position the sprites, and set the colors, etc. for a particular screen only when you're ready to draw that screen. That is, you can't define a string of multiple playfields all in a row, or a string of multiple player0 or player1 shapes all in a row, etc., because if you do that then each of them will be drawn one afer the other very quickly and only the last one in the list will be displayed. It's the same reason why you wouldn't want to do something like this: a=1:a=2:a=3:a=4 When you execute those statements, a will be set to 1, then 2, then 3, then 4-- but after the statements have finished executing, a will be 4. Likewise, you shouldn't code four playfield statements in a row, because when the playfield statements are finished executing only the last playfield will be displayed. The simplest way to have multiple screens is to put each one in a separate subroutine. You do *not* need to put each screen in a separate game loop. On the other hand, you might want to have separate loops for screens that use different logic, like one loop for a title screen and a different loop for the game screens, so the title screen and the actual game screens can be programmed to respond to the console switches and game controllers differently. If you handle the logic for several screens within the same loop (because all of those screens use the same logic), then you'll need to use a variable to keep track of which screen to display at any given time. You don't need to define the playfield, sprites, colors, etc. each time you execute the loop, just when they need to be changed-- with the exception of the player colors, since they get wiped out each time the drawscreen routine displays the score, as well as anything else that gets wiped out by drawscreen. (RandomTerrain's batari Basic page has information about which things need to be set inside the game loop.) In other words, if (and only if) the variable that keeps track of the screen number gets changed, you can jump to a subroutine that draws the desired screen based on the screen number variable. So a program that uses multiple screens might look something like the following example: rem * to keep track of which screen to display dim screen_number = a rem * to keep track of how many frames have been drawn dim frame_counter = b rem * to specify how many screens there are const number_of_screens = 4 rem * to specify how long to display each screen (in this case, 180 frames or 3 seconds) const frames_per_screen = 180 rem * initialize the variables frame_counter = 0 : screen_number = 255 rem * due to the way on...goto and on...gosub work, the first screen will be numbered 0 rather than 1 main_loop rem * if the frame counter has been reset, draw the next screen if frame_counter = 0 then gosub draw_next_screen drawscreen rem * increment the frame counter frame_counter = frame_counter + 1 rem * if number of frames per screen has been reached, reset the frame counter if frame_counter = frames_per_screen then frame_counter = 0 goto main_loop draw_next_screen rem * increment the screen number to draw the next screen screen_number = screen_number + 1 rem * if the new screen number equals the number of screens, reset the screen number back to the first screen if screen_number = number_of_screens then screen_number = 0 rem * now draw the desired screen based on the screen number on screen_number goto screen_0 screen_1 screen_2 screen_3 rem * to keep the number of nested subroutines to a minimum, I'm using on...goto instead of on...gosub rem * each screen routine will return to the main loop when it's done screen_0 playfield: ................................ ..............XXX............... .............XXXX............... ............XX.XX............... ...............XX............... ...............XX............... ...............XX............... ...............XX............... ...............XX............... ............XXXXXXXX............ ................................ end COLUBK = $1C : COLUPF = $64 return screen_1 playfield: ................................ .............XXXXXX............. ............XX....XX............ ...........XX......XX........... ...................XX........... ..................XX............ ...............XXXX............. .............XXX................ ............XX.................. ...........XXXXXXXXXX........... ................................ end COLUBK = $94 : COLUPF = $CA return screen_2 playfield: ................................ .............XXXXXX............. ............XX....XX............ ...........XX......XX........... ..................XX............ ...............XXXX............. ..................XX............ ...........XX......XX........... ............XX....XX............ .............XXXXXX............. ................................ end COLUBK = $44 : COLUPF = $0F return screen_3 playfield: ................................ ............XX....XX............ ............XX....XX............ ............XX....XX............ ............XX....XX............ ............XXXXXXXXXX.......... ..................XX............ ..................XX............ ..................XX............ ..................XX............ ................................ end COLUBK = $00 : COLUPF = $38 return You wouldn't want to use the same logic as this example in your game, because you wouldn't want to display each screen for a specific number of seconds and then change-- but hopefully this example will give you some insights. multiple_screens.bas multiple_screens.bas.bin