EricBall

So last night I played my first game of PUBG Mobile - and survived long enough to reach #34 and made 3 kills. (And I probably would have done better if the game hadn't glitched and not auto-reloaded my AR.) I'm old enough to have played Wolfenstein 3D and DOOM; but not Quake because I'd stepped off the upgrade treadmill. Multiplayer shooters also didn't interest me as I didn't have the time to sink into playing the games to get good enough not to be cannon fodder. So why am I playing PUBG Mobile? It's free to play and so far real money just gets you cosmetic items. 1 The point of the game is not to see how many other players you can kill, but to see how long you can survive. So the point of the game isn't based simply on how good you are with the in-game guns, but somewhat whether you can avoid combat entirely. And I don't think that's the mindset of many players, who are too used to playing other games where the objective is to kill your opponents. That's not to say being able to take out someone with a well-placed headshot isn't a skill to develop - but trying to go toe-to-toe with every other player is a losing strategy. So what did I think of PUBG Mobile (played on my son's Samsung Galaxy Tab A 9.7)? Fun, although a little frustrating. First, it looks like many of the menu UIs expect a 16:9 display, so there are some strange overlaps and glitches - although this doesn't seem to be a problem in game. Some text occasionally is almost too small to read, again probably expecting a screen more than 1024x768. Graphically the game is impressive - it's frankly amazing given the age and capabilities of the tablet. The frustration comes with the controls. Admittedly creating touch controls for a first/third person shooter is going to be difficult. The developer somehow has to put the functionality of a mouse+keyboard or dual analog stick joypad onscreen without obscuring the screen with controls & the players hands. And maybe some of the frustration is because this was my first game and I was trying to hold the tablet rather than placing it on a table. But I would love to be able to use my son's NES30 Pro controller so I could have the precision of dual analog sticks. The main problem is with the turn / look function. The onscreen joystick does a decent job handling the forward / back / strafe movement (although I wish the sprint-lock was a little closer) but you're supposed to swipe on the rest of the screen to turn - which doesn't seem to work as well. Going in and out of buildings and rooms was frustrating. This also made combat more difficult, although part of the issue was I was trying to use the same hand to look & fire - I need to remember there's a fire button on the left side of the screen as well. I do like some of the UI tweaks which have been made to the mobile version (e.g. shot source indication on the mini-map, auto-pickup / equip). They've managed to put a lot of info onscreen and make the controls otherwise easy to use and understand. So for my first game I did the following, most of which I think helped me succeed: Got out of the plane early (near Severny), spotted a small cluster of buildings and dove straight down for them. The idea is to increase the amount of time for looting before the first play zone shrink. I also wanted to try to avoid early confrontation if possible by not going for one of the well known "high level loot" locations. Unfortunately I did end up getting into a early firefight. Aim down the sights! I'm fairly certain the reason I won my firefights, several against better equipped players) was because I actually aimed. Use cover! Again one of the reasons I probably won a couple of my firefights is I was behind cover. In one case I took defeated a player armed with an AR with a shotgun because I hid behind my vehicle. Stuff I need to do better next game: Use healing after a firefight! I might have survived the last one longer but I hadn't healed up from my previous encounters. Reload! The game was auto reloading, and then it stopped and I didn't think to tap the button. Auto pickup ain't perfect. I probably would have been better with a pistol and a shotgun rather than two shotguns. Anyone else playing PUBG Mobile? 1 I think PUBG missed an excellent monetization opportunity. Keep the free to play idea - but when playing for free you don't get to select your character name (it's set to PU#<random number>), your character skin (again randomized - this game you're a Chinese chick with long blonde hair), etc. But for a token micropayment (subscription?) you can pick your character name, skin, and are included in any ranking boards etc.

Sears Canada is already dead. Target Canada only existed for 2 years. Being a brick & mortar store is difficult against online retailers. However, I don't think it's impossible - you just can't make as many mistakes. The online retailers are also making it more difficult for consumers by offering far too many options with too little good information.

I suspect the batteries was a design decision : easier to put the console (with the controls built in) where it's needed & one less cord to trip over save the cost & weight of a wall wart (which were massive in those days) or the expense of getting a built-in power supply UL certified The color is interesting, it looks like they added the output of a custom 3.595 280 MHz crystal (colorburst + one extra cycle per line) to the normal black & white signal. Not sure why they decided to go with built-in speakers rather than adding the audio to the video output before modulating it for channel 3 / 4. Maybe a cost saving measure again - not sure what the extra modulation circuitry would have cost.

Programmers tend to have their own projects, so it's normal for other people's ideas to be ignored - no matter how pretty the mock ups. However, if you have skillz making POKEY (or TIA) chiptunes, then I am sure there are lots of programmers who would really appreciate your help adding music to their projects.

More that Sony recognized they needed third party developers to survive & succeed. So by the time the N64 hit the shelves in Japan the PS1 already had nearly 100 titles available (and certainly more announced), versus the three N64 launch titles. Ben's analysis is basically the same as mine. (Although I do not believe it was possible for the N64 to execute code from the cartridge directly. Based on the docs I've found, I think everything had to be copied to RAM first (and decompressed for some games). )

That's what I mean by "virtuous cycle" - consumers buy consoles based upon the games available for that console; developers develop games for a console based upon expected sales, which is strongly dependent upon the number of people who own the console. For N64 "killer apps", see https://en.wikipedia.org/wiki/Nintendo_Selects#Nintendo_64for a list of games which sold over a million copies. For me, Super Mario 64 was the (literal) system seller, but then I had to wait many months between games worth buying.

The guy who created it also had the only info I could find on the N64 GPU (without digging into emulator source code / repositories).

This past Christmas I bought an N64 for my son (and me) to enjoy my collection of games. (Although the problem turned out to be dirty cartridges rather than a dead N64.) He's been having a blast playing Super Mario 64 and the Mario Party games. This nostalgia rekindled my interest in what is under the hood of both it and the original PlayStation. It turns out there's a lot of similarities between the two, more than I would have expected. Both used a MIPS CPU (PSX: 32bit R3051 @ 33.8688 MHz, N64: 64bit R4300 @ 93.75MHz), both have a vector coprocessor (PSX: Geometry Transformation Engine, N64: Reality Signal Processor) and a graphics / triangle / texture processor. Of course there are the obvious differences too. The N64 is cartridge based, while the PSX is CD based. The PSX has a macroblock decoder for video decompression. The PSX GTE is integrated with the CPU (similar to the old 80x87 math coprocessors), while the N64 RSP has dedicated instruction & data RAM (like the SPEs in the PS3 Cell processor). The N64 has 4MB of main memory (500MB/s) while the PSX has 2MB of main memory (132MB/s) plus 1MB of memory dedicated to the GPU and 512K of memory dedicated to the sound processor. And even though the N64 had better "numbers" (e.g. CPU clock) than the PSX, Sony sold three times as many PlayStations as Nintendo sold N64s. And I have some theories why: First, Sony released the PlayStation 20 months before Nintendo released the N64, which gave them definite traction in the marketplace. The N64 launch library was also very thin (no matter how good SM64 was). Developers could already see the "virtuous cycle" starting with the PlayStation. Second, Sony's decision to use CDs (an easy decision for them given they helped invent CDs) and Nintendo's decision to stick with cartridges had a huge impact for multiple reasons CDs allowed developers to store more - more game content and/or prerecorded audio & video (which the built-in decoder enabled) lower manufacturing cost, it cost much less to press a CD than to manufacture a cartridge so higher profit per sale at a given price I heard that one of the reasons Nintendo stuck with cartridges is Nintendo did all of the manufacturing (charging publishers up front for runs of cartridges to boot), whereas the PlayStation CD could be replicated by nearly anyone who could press CDs. [*]Third, while Nintendo provided developers with C libraries, they didn't provide any low level details. And the provided graphics libraries were much slower than the "numbers" would suggest. So unless you were willing to spend a lot of time & effort reverse-engineering the libraries (e.g. Rare & Factor 5), it wasn't possible to fully exploit the N64 hardware and work around limitations. On the other hand, early third party developer Naughty Dog was able to leverage the PlayStation hardware at a very low level. [*]Finally, although the unified memory on the N64 allowed the CPU & RSP to update the frame buffer (which causes problems with emulators today), I suspect this caused bottlenecks in memory access (especially random access due to the latency of the Rambus memory).

Back in 2009-ish when the transition to HDTV occurred, I built a high gain UHF antenna and used it for a while. But once I got a Rogers HDTV PVR* there hasn't been any point - unless I want to watch the US Superbowl commercials. (I already subscribed to cable to get the premium sports channels.) Unfortunately, there's a lot of misinformation about HDTV and antennas floating around out there and a lot of "HDTV antennas" are more style than substance (i.e. they are good looking junk). However, while the signal has changed from analog to digital, radio waves are still radio waves - so the basics of antennas haven't changed in 80+ years of television broadcasting. Reception follows some simple rules: 1. Height improves reception, outdoors is better than indoors 2. Bigger antennas have better reception, but are more directional 3. Better design, materials & build = better reception Also, a good preamp (mounted at the antenna) helps with long cable & splitter loss & noise but doesn’t actually improve reception. Some links to websites which help with getting more out of your antenna: Reception info: http://www.tvfool.com Map with antenna aiming: http://www.sjmillerconsultants.com/ota/ For all kinds of info on OTA, including building your own antenna visit http://www.digitalhome.ca/forum/forumdisplay.php?f=81 * I originally got the HD PVR as compensation when Rogers made my dual-tuner TiVo less useful by moving the majority of their SD channels to digital. Since then the majority of channels have moved to HD-only and I've bought three refurbished HD PVRs and added an external drive to one of them.

<rimshot>

Over Christmas we watched all of the Star Wars movies (in story order) before going to see Last Jedi. One of the things I liked about Last Jedi is how many of the plot points didn't take the easy & predictable ending. There were lots of times where I thought, "that isn't what I expected". Can someone explain why Vice Admiral Amilyn Holdo didn't reveal her escape plan to Poe? Not doing so makes it seem like she had no plan, which kicked off the whole Finn / Rose stoyline that ultimately resulted in the First Order learning of the plan. And while I could nit-pick the film to death, it was a decent addition to the Star Wars films - certainly better than it's immediate predecessor and in the top half of the list. It will be interesting to see where the story goes from here as the Rebel Alliance tries to recover from being effectively wiped out from a military perspective.

(See previous entries for more info on the game.) It's surprising what a little motivation and enthusiasm can accomplish. One big help was I reached out to YouTuber Torogadude and asked if I could use his compositions as background music and he agreed. Bonus! I've also added sound effects and knocked a lot of other items off my to-do list, which leaves really only three big ones: Revise the embedded HTML "About" pages and try to fix the back navigation so it goes to the previous page rather than the back to the main menu. Also update slidetiltroll.walkerville123.ca to match Review the Apple Guidelines to make sure there isn't anything I need to do before I submit it. Do a code walkthrough and tweak / fix as required

I'd disagree with that. Nearly all of my employer's corporate apps (e.g. the apps they tell me to use as part of my job) are browser based, or have browser versions. Yes, my corporate laptop runs Windows 10, but I could probably do my job just as well with a MacBook and possibly even with a tablet. Kinda like that iPad Pro commercial - is it a computer or something else and does it really matter?

I'm back to working on my iOS game "Slide Tilt Roll" in preparation to using it for a presentation to some computer students at my son's high school. I updated the MacBook to High Sierra, updated to XCode 9, installed XCode 8 to upgrade the code base from Swift 2.2 to Swift 3.0, then used XCode 9 to bring it up to Swift 4.0. That worked for 90% of the code, then I needed to go through and manually fix a few errors and warnings (mostly confined to sqlite and CGPath functions). I've also tweaked the launch and main page backgrounds to display better on the iPhone X - I wonder if I can use one of them at the Apple Store for a quick test The next big thing is to add sound effects and music. I've found a paper for some algorithmically generated music which will I will hopefully be able to use. I'm still looking for anyone willing to create levels to supplement the ones I have created programatically. Interested? You need an iPhone, iPad or iPod Touch running iOS 9 or later (configured to send email) and a willingness to create levels gratis for my 100% free application. In order to install my app I need the UDID for your device. This can be obtained from iTunes by clicking on the Serial Number on the device Summary panel, then right clicking on the hex digit string, selecting copy, and sending it to me via PM. (If you don't have iTunes, you can get it by plugging into a computer and looking at the USB device information. Ask, and I'll provide instructions. Any other methods (websites, apps) are either outdated or extremely suspect.) After I get your UDID I will update my Apple Developer account device list and send you the link to download and install. Muchas gracias Merci beaucoup Vielen Dank

Yep, I was about to give you that link, but you beat me to it. It really comes down to how much CPU time is available. While the 7800 GPU is capable of displaying more sprites (total and per line) than the NES PPU, each 7800 sprite requires a significant number of CPU cycles to move around the screen, whereas on the NES the CPU cycles are trivial. Then to make matters worse, because of the unified memory the 7800 CPU loses even more cycles for each sprite & tile displayed.

One of the trickier parts of programming the 7800 is working through the 7800 graphics modes and how to map colors to sprite data, particularly for the 320 modes. Although I've given this info before (except for 320D), I'm hoping that the following will be useful to anyone wanting to program the 7800 or hack existing games. 2019-05-29 I have attached a spreadsheet which breaks down this data into a (hopefully) more usable form. 160A (WM=0,RM1=0,RM0=0) 2 bits per pixel, 3 colors + background/transparent from 8 palettes D7531 D6420 palette = P2 P1 P0 0 0 BG / transparent 0 1 C1 1 0 C2 1 1 C3 160B (WM=1,RM1=0,RM0=0) 4 bits per pixel, 12 colors + background/transparent from 2 palettes D75 D64 D31 D20 P2=0 : palette 0-3, P2=1 : palette 4 -7 0 0 0 0 BG / transparent 0 1 0 0 P04 C1 1 0 0 0 P04 C2 1 1 0 0 P04 C3 0 0 0 1 BG / transparent 0 1 0 1 P15 C1 1 0 0 1 P15 C2 1 1 0 1 P15 C3 0 0 1 0 BG / transparent 0 1 1 0 P26 C1 1 0 1 0 P26 C2 1 1 1 0 P26 C3 0 0 1 1 BG / transparent 0 1 1 1 P37 C1 1 0 1 1 P37 C2 1 1 1 1 P37 C3 320A (WM=0,RM1=1,RM0=1) 1 bit per pixel, 1 color + background & transparent from 8 palettes D7531 D6420 palette = P2 P1 P0 0 0 BG + BG / transparent 0 1 BG + C2 1 0 C2 + BG 1 1 C2 + C2 320B (WM=1,RM1=1,RM0=0) 2 bits per pixel, 3 colors + background & transparent from 2 palettes D75 D64 D31 D20 P2=0 : palette 0 P2=1 : palette 4 0 0 0 0 BG + BG / transparent 0 0 0 1 BG + C1 / transparent 0 1 0 0 BG + C2 0 1 0 1 BG + C3 0 0 1 0 C1 + BG / transparent 0 0 1 1 C1 + C1 / transparent 0 1 1 0 C1 + C2 0 1 1 1 C1 + C3 1 0 0 0 C2 + BG 1 0 0 1 C2 + C1 1 1 0 0 C2 + C2 1 1 0 1 C2 + C3 1 0 1 0 C3 + BG 1 0 1 1 C3 + C1 1 1 1 0 C3 + C2 1 1 1 1 C3 + C3 320C (WM=1,RM1=1,RM0=1) 2 bits per pixel, 4 colors + background & transparent from 2 palettes D75 D64 D31 D20 P2=0 : palette 0-3, P2=1 : palette 4 -7 0 0 0 0 BG + BG / transparent 0 1 0 0 P04 BG + C2 1 0 0 0 P04 C2 + BG 1 1 0 0 P04 C2 + C2 0 0 0 1 BG + BG / transparent 0 1 0 1 P15 BG + C2 1 0 0 1 P15 C2 + BG 1 1 0 1 P15 C2 + C2 0 0 1 0 BG + BG / transparent 0 1 1 0 P26 BG + C2 1 0 1 0 P26 C2 + BG 1 1 1 0 P26 C2 + C2 0 0 1 1 BG + BG / transparent 0 1 1 1 P37 BG + C2 1 0 1 1 P37 C2 + BG 1 1 1 1 P37 C2 + C2 320D (WM=0,RM1=1,RM0=0) 1 bit per pixel, 3 colors + background & transparent from 2 palettes P1 P0 D7531 D6420 P2=0 : palette 0 P2=1 : palette 4 0 0 0 0 BG + BG / transparent 0 0 1 0 C2 + BG 0 0 0 1 BG + C2 0 0 1 1 C2 + C2 0 1 0 0 BG + C1 / transparent 0 1 0 1 BG + C3 0 1 1 0 C2 + C1 0 1 1 1 C2 + C3 1 0 0 0 C1 + BG / transparent 1 0 0 1 C1 + C2 1 0 1 0 C3 + BG 1 0 1 1 C3 + C2 1 1 0 0 C1 + C1 / transparent 1 1 0 1 C1 + C3 1 1 1 0 C3 + C1 1 1 1 1 C3 + C3 MARIA.zip

Just a suggestion - don't put the cart (graphics) before the horse (code). In addition to the size of the sprites, the artist is going to need to know the graphics mode / palette. And for anything other than static sprites, they are going to want to know something about how the sprites move and need to be animated. ROM space might also be a factor. You can do a lot of coding with temporary sprites and be in a much better position to know what you need the artist to provide and the limitations they must work inside.

Awesome Video Game Data 2017 Based on the data, I'd say console still has life for a couple more years. As long as there's money to be made, consoles will still exist.

There's no problem using a POKEY (or any other chip which drives the cartridge audio pin) and the TIA at the same time. The problem is updating the TIA at a high enough frequency to make any sampled audio worth it. Updating the TIA once per frame (60Hz) is trivial, but after that it gets considerably harder. You could use the DLL NMI to update it once per zone, i.e. every 8 lines = 1967Hz or every 16 lines = 983Hz, but you will have to adjust for 23 lines of VBLANK. Similarly, you could bang on WSYNC and update the TIA every line (15,734 Hz), but that will waste a lot of CPU time and you'll still have to handle VBLANK (unless you're only playing music). Note: 2 or 4 bit won't make any difference except for how much ROM space the samples use. You will also need to consider how much CPU the update routine will require. I'd recommend seeing if the native TIA waveforms can provide any of the sound effects and update the TIA once per frame.

Whether a games platform lives or dies depends on whether it can build and maintain what I call the "virtuous cycle". Developers want to create games for platforms where there are a large number of consumers who are likley to buy the game. Consumers buy game platforms which have games they want to buy and play. The more people who have the platform, the more developers are likely to create games for that platform and the more games for the platform, the more consumers are likely to buy into the platform. However, the mobile platforms, cross platform development and freemium pricing models has broken this idea. People no longer have to buy into a gaming platform because they already bought into it for other reasons. Freemium pricing models also drop the cost to consumers to play games, although developers suffer because more people playing doesn't mean more people paying. Consoles largely can't compete in this space. Why pay hundreds of dollars for a console instead of using the mobile device you already have? Why pay $60 for a game when there's a huge library of "free to play" games? Consoles can only compete by offering complex, big-screen games which mobile can't, i.e. competing with PC gaming. And as HoshiChiri notes, the one advantage consoles have over PCs is uniformity. Consumers can buy games knowing they will work and developers can develop for a single target. Developers also like that consoles are more locked down than PCs, which helps prevent privacy and cheating. Unfortunately, developing those complex, big-screen games has a very high up-front cost, which puts it out of reach of a lot of developers and increases the downside if a game doesn't sell well. Without enough developers creating possible system sellers, consumers aren't going to buy the consoles, and the "virtuous circle" collapses. Maybe consoles will become like iPhones - periodically Sony and Microsoft will release the next generation of the Playstation and XBox, like the PS4Pro and XBox One S&X, which maintains backwards & forwards software compatibility while providing more CPU & GPU power for games to tap into and graphics improvements like 4K & HDR. Or maybe consoles will move to the cloud, e.g. OnLive style gaming.

And as someone who has programmed for both the 2600 & 7800, I agree with Kosmic Stardust - start from scratch. Have a look at your A8 code - how much of it is concerned with setting up the ANTIC display lists? Throw that out; MARIA display lists are radically different from ANTIC display lists. Next, how much of the remaining code is designed to make the code you just threw out easier / better? Throw that out too, you'll need to redo that code to make the code to set up the MARIA display lists easier . Sound? Throw it out, you only have a TIA (2 channels & half the frequency resolution). Controllers? Throw it out - different controllers and digital instead of analog. Graphics data? Throw it out; MARIA does 4+ colors per pixel. Collision detection? Throw it out, the 7800 doesn't have collision detection registers. Now, take a look, how much code is left? Is any of it worth saving or are you better off starting off with a clean page (and maybe even using 7800 Basic). At one point I did a write-up on the 7800 versus the 5200 : https://sites.google.com/site/atari7800wiki/atari-5200 which might help you as a starting point.

You'd think at some point the lenders would start to question whether they were ever going to get paid and stop throwing good money after bad.

Define "higher quality". The TIA (and POKEY for that matter) are simple LFSR based waveform generators. From a programming perspective there are three inputs for each of the two channels: AUDF, a 5 bit divisor of 2 * the horizontal retrace frequency AUDC, a 4 bit LFSR selector, which controls the AUDF frequency to waveform AUDV, is a 4 bit volume control of the waveform output The problem is these values are hard coded into the game ROM. So even if you added an extra bit into one of the registers, the games wouldn't be able to use it. What you could do is tap the output TIA audio output pins (12 & 13) and put them through a high quality amplifier / filter. This will also expose some "stereo" effects in some games.

Two controllers work fine. My son and I played some 2 player Joust and Super Mario Kart (slow). As for it being underpowered, it really depends upon your expectations. Will it play a lot of games from the 8 & 16 bit generations - YES. Will it play every game perfectly - NO. Also, while Lakka tries to be easy to use, there are areas where it's not there yet. So expect to have to do some forum/doc/Google research and stuff from the command line.

I now have MAME (2003 - 0.78) up and running, woot! I've loaded up "the best of" from pre-1986, now I need to figure out how to set the controls beyond the defaults. This also means I can play the originals rather than the console ports. I'm also working on getting Colecovision running. I've created a script which creates a playlist from a directory of zip'd ROMs, as Lakka doesn't seem to auto recognize them. Unfortunately, the CV emulator is also the MSX emulator, so I need to figure out how to put it into CV mode while not impacting the MSX ROMS. Hopefully I can use symbolic links to create a separate configuration. I've also discovered some additional ROM collections on the MAME DVD sets I have from back in the day. Lakka also includes a bunch of emulators which I haven't tried out yet, including SCUMM VM for playing various point & click adventure games. I wonder if I have Leisure Suit Larry on my historical backup drive.