EricBall
-
Content Count
2,362 -
Joined
-
Last visited
Blog Comments posted by EricBall
-
-
I'd been working on my own DVDs from my laserdiscs, but since it's inevitably going to be at least two generations further away from the original source, it just couldn't compare.
I'd been doing the same thing with my VHS tapes. What impressed me was how well my efforts stacked up against the real thing. The SE DVDs also have a commentary track which is an interesting listen.
-
I can't say I have as many copies of Star Wars as you do. I also have ex-rental VHS versions of the original trilogy along with the THX widescreen versions on VHS. But I avoided buying the SE DVD since I'm a purist when it comes to the original trilogy. (I did see the SEs in the theater. Hated the edits then too.) But I did buy the Collectors Edition so I now have the Original Theatrical Release on DVD (even if it is letterbox).
-
<i>How is it possible to both love and hate old computers so much at the same time?</i>
I have a hard enough time not hating new computers. Windows XP is great at handling things automagically, but gods help you if they don't. ([email protected]#[email protected]#$ no-name VT6212L USB2 card)
But when I was archiving my PC 5 1/4 collection a few years ago I tried to fire up a couple of GUS games. After spending ten minutes fussing with config.sys and autoexec.bat (without success) I got this shiver. I remember a time when this endless tweaking was almost fun! And you're lucky, you had a NIC. I had to transfer my files using a serial cable and some long forgotten MS pseudo networking utilities.
-
You might want to find out who owns the Le Mans games. Maybe you can pick up one for home.
-
There was a Wired magazine article a few years ago talking about F.L.A.G. (fibre optic link around the globe) which also had a history of the early transatlantic cables.
And you can have repeaters on undersea links, it's really a matter of supplying power to them (carried in the cable).
4KHz is normal telephone bandwidth. It likely sounded tinny because the low frequency parts of the signal were attenuated.
-
Maybe prevent drop-offs only when the player is above the enemy? Then enemies would avoid holes only when the player has managed to climb a ladder after digging the hole and before it filled in.
Duh. You're right. I was originally going to have the enemy walk off the edge on Y equals, but then changed my mind.
-
It's not just the one byte, I need to retrieve the same bit from 8 bytes.
GRID LDY YPOS_TMP; check current position GRID_Y LDA XPOS_TMP LSR LSR ; implicit CLC TAX GRID_X LDA XBANK,X ; get bitmap bank STA PF_PTR+1; set up pointer LDA #$00 STA PF_PTR LDA XFBIT,X ; bitmap mask TAX ; save mask GRID_Q LDA #$01 ; initial value (8 shifts) STA PFOUT 1$ TXA ; load mask AND (PF_PTR),Y BEQ 2$ SEC ; shift in 1 2$ ROL PFOUT INY BCC 1$ ; keep looping until 1 shifted out LDA PFOUT RTS
-
For us homebrew developers, emulators make the process much easier. Code, compile, test (and sometimes debug) on a laptop you can take anywhere. And, as you mention, emulators have the advantage when it comes to space, cost & reliability.
And you're also right that where emulators differ from the real thing is when it comes to accurracy. Stella & Z26 are near perfect when it comes to emulating the 2600 (although I don't know whether they could drive a TV the same), but none of the existing 7800 emulators handles DMA cycle stealing and the Vectrex or GameBoy had dedicated displays which can only be emulated, not duplicated.
-
I tried it only briefly, but I couldn't get enemies to fall from ropes.Yeah, that isn't in the code yet. I've got a bunch of special cases I want to put in including:
1. fall from ropes when the player is directly beneath
2. jump off ladders if the player passes directly beside (tag!)
3. look ahead for drop-offs (only drop off if the player is to that side and below)
4. look ahead for getting off ladders
But first I'm trying to see if I can think up some reasonable hunt logic which the enemies would use when they can't go towards the player. The actual issue is how to determine when to stop and go back to normal chase logic.
I also want to add some code so enemies avoid overlapping each other. I may also put in the "walking on heads", though it may be tricky to walk over more than one enemy.
Hmm... just realized something. If I add in the drop-off look ahead then the enemies won't fall in holes! The law of unintended consequences at work.
-
Up here in Toronto one of the new stations (92.5 CJAQ aka Jack) has gone to a no-DJ, mega playlist (I think 70s-90s, heavy on the 80s, with the occasional older/newer) format. No requests either (except for a special charity promotion once).
Oh, and since you're in the biz, has anyone ever tried going with (very) short commerical breaks rather than the typical lots of songs / lots of commercials format? I'm thinking that listeners would be more likely to stick if they knew the music would be back after the one ad, rather than skip around the dial.
-
In what order is your bitmap data stored? I would think it should be possible to do bitmap lookups pretty quickly.
It's a raw PF bitmap. So the code has to AND out the right bit of 8 bytes, which requires over 200 cycles. However, I'm seriously considering adding some kind of "look-ahead" at least for the ladder case, i.e. if the player is in the same row, can the enemy go that direction without falling?
-
Surely the movement routine has to know what directions the enemy can move at any given time. Is there any reason that information can't be used by the AI?
Yes/no. The DO_GRID routine does the minimum number of tests necessary to detemine the player/enemy action based on current position & joystick direction. This is because figuring out the type of grid square is computationally intensive because it's based completely on the playfield bitmap. (Although I may add in some player/enemy tests to allow them to walk on each other's heads.) So I'd like to avoid that if at all possible.
Also, since you're giving the monsters different colors, would there be any problem giving them slightly-different algorithms?
I'd considered the idea. Let's see if I can come up with one decent algorithm first. The one problem with your suggestion is it will probably lead to too much "mind control", i.e. enemies going back & forth (or up & down) in response to the player rather than discovering some way to get closer.
-
I had an idea on the way home from work. Basically leverage the last action as state info. Thus:
falling/dead - point joystick to player
stopped - go into a hunt mode, rotating the joystick around
running - continue in same direction (right/left) with up/down pointing to player
climbing - continue in same direction (up/down) with right/left pointing to player (maybe with some smarts to grab the player if they are next to the ladder
swinging - continue in same direction (right/left) with up/down pointing to player, maybe with some code to fall down if the player is directly beneath
Remember, if the enemy (or player) is on a ladder the joystick->action subroutine will give up/down priority, which will start the climb automatically.
About the only place this doesn't work is if the ladder goes through or past a platform, since that will mean the enemy will keep climbing even if the player is on the same row.
-
iPod - yes, although really it's my wife's (and it's a Photo unit I picked up off eBay)
MySpace - yes, though only a private blog for my extended family (and I hate the interface)
-
I confess, I spent little time playing the multiplayer modes; focusing on the one player mode so I could try out the various microgames. I'd forgotten some of the inter-player interaction.
Still, I'll stick to one of the Mario Party games for multiplayer.
-
So when are we gonna see the Leprachaun editor that runs native on the 2600 and saves to tape? :-)
It should be technically feasible, although it would require some kind of VCS to audio out interface (either tapping the TV audio out or something via the joystick port). The level editor itself wouldn't be difficult; heck, it wouldn't be tough to adapt the existing kernel. Unlike the web LLE, it would only save the level data, not a working game. It could load that level data, same as the full game. Also, unlike the web LLE, any changes to the game level format would make any previously created levels invalid.
But the big disavantage, IMHO, is it would be much more difficult to share levels you've created.
-
I reloaded an old level and resaved it - now the binary won't run at all.
Dang, dang, dang. I must have messed up the lepsave.php+base binary somehow. Let me see how fast I can fix it.
(update) Fixed & tested.
-
Widescreen TVs have less of a problem with resolutions since the input (NTSC - 4:3 480i/p or HDTV 16:9 720p/1080i) doesn't have the same variations. However, scaling is required since no single native resolution will handle both HTDV resolutions.
But a bigger issue is connectivity. Don't buy a widescreen TV without an HDMI input which supports HDCP.
-
ignoring phase, since it's virtually impossible to control the phase of the TIA audio waveformIs the TIA audio not deterministic, with the main input getting hit exactly twice per scan line? I should think that it should be possible to control the phase precisely on a real 2600 (at a worst-case cost of about 17 scan lines per frame)
Oh, yes, it's deterministic, just not easy to control / predict. A collorary would be the digits of pi - the sequence is always the same, but it's impossible to predict the next digit even if you know the previous digits. The problem with the TIA is changing AUDC/AUDF doesn't reset the state of the LSFRs or counter - they continue from the state they were in.
The TIA audio generator has three main sections. First is the frequency divisor - a 5 bit up counter which is reset to 0 when AUDF is reached. The problem is if the current value of the counter is greater than AUDF, then it keeps counting up before wrapping around from 31 back to zero. So, to know the phase of the output, we have to track the exact value of the counter.
The next two sections are the LFSRs - a 4 bit and a 5 bit which can interact with each other. Again, changing AUDC doesn't impact the state of the LSFRs, but unless the state of the frequency divisor is known exactly, there's little point in trying to track the LSFR state.
So for simplicity sake, it doesn't make sense to try to determine the exact phase of the output waveform. For although it might be possible to predict the phase of the output, controlling would be much, much more difficult.
And from an desired output it doesn't make much sense either. If the TIA is 90 degrees out of phase from the sample waveform, then it won't match; even though it might be otherwise correct. Finding frequency matches is tough enough without worrying about phase.
-
Hm... it sounds like putting a C64 tape into an audio cassette player. Until you said so in this message, I'd never even thought it's supposed to be music, let alone "Get Ready for This" ...
Yeah, my wife said the same thing. Once she knew what it was, she could hear the similarity. 'Twas an experiment.
-
You are changing AUDxx once per frame, correct? How much better would it sound to go to two or three times per frame?
It might, but I don't think it will get much better unless you instead bang on AUDF and do 4-bit PCM instead. (Of course, that chews up ROM really, really quick.)
Double the data rate, double the ROM required (or half the time). But that also doubles the lowest frequency which can be determined using my method*. I suspect this would also pick up more high-frequency false noise.
* Note for those interested, there are 123 NTSC TIA AUDC/AUDF combinations which have a fundamental frequency of less than 60Hz.
-
I've been disgruntled with the whole "working with video files" thing when I couldn't find a program to turn a movie 90 degrees.
I know AVISynth can (TurnRight/TurnLeft), VirtualDub might be able to as well, though they might require a plugin to handle your source format.
-
1
-
-
Activision asked that the ROMs be removed, AtariAge complied with the request. Other websites may have different rules and thoughts on copyright, but AA tries to respect the wishes of the copyright owners. (There are other examples, like the Ebivision carts.)
-
That just halves the house percentage from 1/37 (2.7%) to 0.5/37 (1.35%), it's still the same no matter whether you bet on 18, 12, 9, 6, 4, 3, 2 or 1 number.From my understanding, suppose you bet $18 on "even". If an odd number comes up, you lose. If an even number comes up, you get $36. If a "0" comes up followed by odd, you lose. If a "0" comes up followed by even, you get back $18.
Suppose you instead bet $1 each on 2, 4, 6, 8, etc. If an odd number comes up, you lose. If an even number comes up, you get $36. If a "0" comes up followed by odd, you lose. If a "0" comes up followed by even, you get back the $1 you bet on the particular number that came up, and lose the other $17.
Let's look at it from $1 red bet.
first spin red (18/37) returns $2
first spin black (18/37) returns $0
first spin 0 (1/37), second spin red (18/37) returns $1
first spin 0, second spin black or 0 (19/37) returns $0
EV = $2 * 18/37 + $0 * 18/37 + $1 * 18/37 * 1/37 + $0 * 19/37 * 1/37
EV = 36/37 + 18/1369 = 98.6% (versus 97.3%)
HP = 1.39% (versus 2.7%) (okay worse than 1.35%, but I didn't factor in the second 0 spin)
Now, reading http://www.casinomontecarlo.com/en/games/t...an_roulette.pdf it sounds like when 0 is spun bets lose half thier value. So there's still a 36:1 payout on single numbers (just for half the bet).
In any case, the important thing is to realize the EV/HP doesn't depend on the bet. So for a single number bet:
EV = $36 * 1/37 + $18 * 1/37 * 1/37 = 98.6%
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
McPeople
in Flack's Daily Smack
A blog by Flack
Posted
I have to confess that I did work for McDs back in my later high school years. Completely messed up my sleep patterns for a while working weekend maintenance/open. But even then, I often referred to some of my co-workers as mutants. I guess I was just a few years too soon.