Jump to content

EricBall

Members
  • Content Count

    2,361
  • Joined

  • Last visited

Blog Entries posted by EricBall

  1. EricBall
    I got the Raspberry Pi 3A+ last week and the HDMI to DVI adapter finally showed up on Friday.  So I immediately hooked everything up and started to redo the setup (fortunately I'd tried to keep notes for most of the config changes).  I had powered the Zero off the USB hub built into the monitor which meant I could turn both on and off with the monitor's power button.  At first I did the same with the 3A+, but I got occasional "under voltage detected" errors.  At first I ignored it as it didn't seem to have any impact, but then RetroArch mis-recognized the Xinmo controller and I knew a change was necessary.  So I switch to using a standard wall wart and started over.
     
    But I really wanted to be able to turn both the monitor & Pi on and off with one switch - ideally with the monitor's power button.  If I couldn't use the built-in USB hub, maybe I could use the 12V jack used to power a speaker.  In fact, before I bought the USB powered speakers I'd looked into some 12V audio boards for the RPi, hoping there would be a reasonably priced option (ha!) which would also power the Pi.  What I wanted was something cheap which would convert 12V to USB power.
     
    Then it hit me - cars are "12V" (not really), but I bet I could crack open a cheap (dollar store cheap) car lighter USB adapter, solder on a cable with the correct barrel connector and have a probable solution.  A couple of hours later I had done just that - and it worked perfectly!
     
    Moving up to the 3A+ has also increased the number of potentially playable games - although this time I'm starting out with just 44 from a combination of "best of" lists.  So I need to go through those, make sure they work (near) perfectly, then make up the media for the front end.  I also need to finalize the control panel artwork (I've decided to just use heavy-duty vinyl, so no need to try to cut & bend plastic) and then I can build the final cabinet!
  2. EricBall
    The other day I learned lr-mame2000 doesn't save high scores.  Part of me thinks I should just accept it.  But the more I play the more I want to have the high scores saved over time.  Being on or first on the high score table is part of the arcade experience.  (Ideally I'd love it if Libretro saved the entire system state on exit so it wouldn't have to go through the initialization sequence.)  And while lr-mame2003 does support high scores, it needs more CPU.  So either I'd end up cutting my list of playable games even more or I need to get another RPi - and I'd rather not spend even more $$ on this project.
     
    OTOH, prior to making my barcade I was using the Raspberry Pi Zero to play back DVD rips (no problem with the MPEG-2 decoder licensed/enabled); so in the long term I'd want to buy a second RPi anyway.  (Heck, I suspect eventually I'll get a third to hook up as a retro console.)
     
    So two good reasons won over my frugal nature and I bought a Raspberry Pi 3 A+, which fits my requirements perfectly.  I've ordered 
     
    Of course now I will need to go back through the list of games and see if there's any other "best of the best" which are now playable.
     
    For the actual build the current bottleneck is creating artwork for the control panel.  Much to my relief others have confirmed vinyl is durable enough for the control panel and it's not necessary to cover it with plexiglass or lexan.  This great because I suspected it would take me several tries to successfully bend & cut holes in the plastic (plus I'd need to buy a bit for my router).  My plan was to use macro photos of quarters as a background.  However, it's amazing how scratched a quarter can be even if it looks "mint" under a magnifying glass.
     
  3. EricBall
    Focusing on the "best of the best" games was a very good idea. It meant I only had to do marquees, attract videos and control panel diagrams for 19 games rather than over 100.
     
    This is a screenshot of my Attract Mode theme.  The marquees are instead of the more typical text game list.  And when the game is selected it shows a video of the game's attract mode.  The bottom is a basic diagram of the cabinet control panel to show which controls are used for what in the game.
     

     
    From a software perspective the system is at the 90% finished stage:
    Go back through the games list and maybe add a few more games. Due to MAME romset differences I only have screenshots rather than videos for a few games. See what tweaking can be done to the boot-up & game start sequences to make them quicker & avoid text displays.  
    However making the final cabinet is almost more important.  But I'm really struggling with anxiety about having everything go right.
     
    At least it's playable - so I'm going to go play some games.
  4. EricBall
    The first pass through the vertical games has been completed!  I've marked a little over 100 games as "perfect - include".  So now I'm doing a second pass.  My original thought was to have a second look at the "perfect - maybe" and "playable, 50 fps" (where MAME was skipping some frames) games, but now I'm thinking maybe I might want to whittle down even the main list.  Is it better to have more games to chose from or to try to only include those game which will probably get played?
     
    It was suggested to me to use the "All Killer, No Filler" game list rather than going through the games myself.  While I would have still needed to go through that list to figure out which games would work with my setup, I'm now thinking there might be value in using it to decrease the size of my list.
     
    OTOH, having seldom played games on the system isn't a bad thing; although each game will take some time & effort to find and create the assets (e.g. marque, snapshot) for the front-end.
     
    Update - My wife has stated that more is not better and I should be ruthless in my second pass and, at least to start with, only include "the best of the best" games.
  5. EricBall
    Unfortunately the cardboard box didn't really have the strength to hold he monitor in place.  But I wasn't ready to build the final cabinet (i.e. spend $$ on materials).  Fortunately I was able to build a replacement using a 12x24 shelf cut along the diagonal and some Ikea scraps which were the perfect length.  I used some "hockey tape" to decorate the cut edge.  (Not sure what I'm going to do on the final version as I don't feel like spending the $$ to buy the slot cutter to use T moulding.)
     
    Then I one of the local 'cade shops decided to have a sale, so I picked up a Sanwa joystick for half price along with buttons, a controller & wiring.  This past weekend I made a simple control panel out of a scrap piece of 3/4" MDF - both to mount the buttons so I could start using them, but also to test out my woodworking skills for the joystick mount.  For the final version I'm planning on having a 1/8" top-cover to hide the mounting plate & buttons.
     
    So far it's worked out great except I had planned to use the player buttons to both insert a coin and start the game.  Unfortunately some games don't like this configuration, so it looks like I'll need to have a dedicated coin button. 
     
    I've ordered Logitech S150 USB speakers and they should be showing up this week next month.  I lucked out as the cheap "USB powered" speakers I was planning on using still used a headphone jack for audio rather than USB!  (This actually turns out to be quite common for "USB speakers".)  Before I found the S150 I was worried that I'd have to go to a more costly option.
     
    I'm still going through the games.  There's a lot of games which are playable, but not at full FPS.  While this doesn't impact the gameplay, it also means the RPi doesn't have the CPU power for good audio.
     
    I'm also mulling over how to finish the cabinet.  While I'd love to get some custom vinyl made, I'm not sure of the cost.  Plenty of time to figure that out later!
     

  6. EricBall
    In the words of Sinstar, "Beware, I live"
     

     
    As I mentioned in the previous post, I started over with lr-mame2000 (MAME 0.37b5 as a Libretro core) on RetroPie 4.7.1 (current).  While mame4all-pi is supposed to be faster, it doesn't do me any good if it doesn't support rotation.  It also became obvious that mame4app-pi is basically an unsupported hack.
     
    Once I started over I tried the recommended solution of disabling the internal "soundcard" without success, likely due to the same problem of the USB headset being "card 1" rather than "card 0".  I then re-enabled the internal soundcard and instead configured the system so the USB headset was "card 0" - and it worked!
     
    So this morning I made a stand out of a cardboard box (~20 degree tilt) and tweaked the libretro config to rotate and fill the screen at native resolution (along with rotating Emulationstation).
     
    So now the task is to go through ~450 games to see what's playable and what's worth playing.  After that I can focus on setting up the front end.
  7. EricBall
    While researching for whether anyone else had found a solution for my audio issues, I discovered that mame4all doesn't support screen rotation.  Bogus!
     
    So now I'm going to try to use lr-mame2000 (the same version the MAME core code, but built on top of the Libretro platform) on the current release of RetroPie (4.7.1) - hopefully I won't have as many issues (or it won't be such a headache to resolve them).
     
  8. EricBall
    My current challenges are with getting the audio working - not something I expected, so it's fortunate I realized I could use the USB headset.  I've been working with RetroPie 4.5 as RecalBox is locked down by using a read-only partition.  (So I can't rotate Emulation Station.)
     
    Audio on Linux is handled by ALSA.  It provides a lot of flexibility in order to handle the breadth of soundcards - which means a lot of complexity.  Unfortunately, there's not a lot of good, authoritative, current, how-to documentation.  ALSA also needs to handle three requirements - first is telling ALSA about the soundcards in the system.  Fortunately the automatic detection & configuration is working in this case (although not without a few wrinkles).  Second is the ALSA API which applications use.  Finally there's the part in between - getting the applications (e.g. mame4all-pi) to actually use the soundcard (USB headset).
     
    mame4all-pi uses the "default" PCM "device" (via a hardcoded string).  Unfortunately, the automatic configuration lumps both the internal Raspberry Pi soundcard and the USB headset into the "default" PCM "device".  Disabling the internal soundcard (via the boot config.txt) still doesn't work because the USB headset is still card 1 (rather than card 0).  After much searching, I finally found instructions on how to renumber the two so the USB headset is card 0 and the internal soundcard is card 1.
     
    The next problem is mame4all-pi is hardcoded to use 44.1kHz sampling, while my USB headset only supports 48kHz.  Fortunately ALSA supports plugins to automatically resample as part of configuring the "default" PCM "device".  The next problem is the USB headset doesn't support mono - again fixable via an ALSA plugin.  Unfortunately, mame4all-pi is now throwing another ALSA API error...
  9. EricBall
    While I have made some progress, I've also encountered a bunch of frustration.
     
    The progress is mostly on the hardware side where I realized I could plug the Raspberry Pi back into the monitor's USB hub with a old USB A to B cable via the USB B jack to micro USB OTG cable.  Then I had the second realization I could simply plug in a pair of USB headphones for audio (and use cheap USB speakers in the final build).  While the USB speakers won't be as loud as ones powered by the 12V jack on the monitor - I wasn't finding any cheap 12V amplifiers for the RPi.
     
    The software, however, has been a mess of frustration.  The idea of this project is to rotate the monitor and configure it to play vertical arcade games.  You'd think I wouldn't be the first person to have this idea and it would be a simple configuration option.  While MAME has the support built-in, neither Lakka nor the front end used by other prebuilt system images (EmulationStation) include this function.  Attract-Mode, another front-end available for the RPi, has this function - but it's offered as an add-on to RetroPie rather than as a dedicated system image.  The other option is to rotate the display via a configuration option, but I've heard that has a significant performance impact.
     
    For the Raspberry Pi there are several prebuilt system images based around the Libretro emulation library:
    Lakka - uses the RetroArch front-end which looks a lot like the Sony XMB interface.  No support (AFAIK) for rotation.  Some quirks (e.g. image sets the HDMI option to CEA (TVs) which causes problems with monitors (DMT), conflicts between Colecovision and MSX emulators). Recalbox - uses the EmulationStation front-end which is the typical list + image view.  No support (AFAIK) for rotation.  Basic image has a 3GB FAT32 partition but only 756MB of data which then causes the initial setup to fail on a 4GB microSD card.  Resizing the partition to 800MB works around the problem.  On the plus side it includes a bunch of games with non-commercial licenses and has some nice menu music. RetroPie - uses EmulationStation by default, but has the option to install Attract-Mode.  MAME4ALL doesn't work on most recent version with non-HDMI audio, okay with older version.  Haven't figured out how to get USB audio working.  (Although maybe I can get the necessary info from the Recalbox image...)  
    Update - turns out EmulationStation can be rotated via a command line option.  Unfortunately Recalbox runs from a read-only filesystem so I can't add it.  So my current focus is on getting USB audio working on RetroPie.
  10. EricBall
    There's a saying which goes something like "progress is seldom made in a straight line" - which basically means you can't really anticipate what you need to do until you've started.  But if you're wise you'll minimize your losses.  For me that means spending time rather than $$, which is why I am forcing myself to work out the software before I spend too much on hardware.
     
    Last night I plugged the RPi0w into the monitor (I did buy a mini-HDMI to DVI-D cable as I couldn't assume that would work) and spent a bunch of time trying to figure out why the monitor wouldn't display anything.  It turns out Lakka sets the HDMI to CEA (TV timings) rather than DMT (monitor timings).  This immediately soured me on continuing to use Lakka (which I had started to set up for emulating various consoles) for testing.  This probably wasn't a bad idea as the Lakka front end isn't as configurable, so I almost certainly wasn't going to be using it in the final build.
     
    Okay, so back to the drawing board - which system image to use?  To make a long story short, I decided to go with RetroPie.  It may not be the "best" system image (one of the reasons I was using Lakka is it's minimalist ethos), but it's got decent community support.  So if / when I need help I suspect I'll get it.
     
    But going through the docs it recommend for RPi0 to use mame4all (0.37b5) rather than lr-mame2003 (0.78).  Which mean I need to re-do the work I've done in putting together the vertical collection.  Sigh
     
    So I've re-imaged the microSD card with RetroPie, now I need to get that working & log in to get the xml / dat file.
  11. EricBall
    Several years ago I rescued a number of old 4:3 LCD monitors my employer was discarding, including several particularly nice 20" 1600x1200 Dell 2007 FP.  My plan was to use them to create vertical monitor MAME cabinets.  But having learned from past projects, I resisted doing anything on the hardware side until I'd figured out the software side.  And then, like many of my projects, that's where it waited.  I'd occasionally give the idea some thought, but never really do anything serious.
     
    But more recently I've started giving trying to work out a plan.  The basic idea is to use a Raspberry Pi Zero as the CPU, powered off the monitor USB ports.  The monitor also has a 12V power port which could be used to power speakers - but that's hardware so something for later.
     
    From a software side it appears there are a few different front ends which could serve.  Basic idea is to select game via a very simple grid which plays attract mode videos.  This appears to be doable.
     
    But that brings up the question - what games?  The current plan is for a minimalist control panel - joystick plus two or three buttons (depending upon what the games require).
     
    I already have Lakka on an SD card for my Pi0w which has MAME 0.78 (aka mame2003).  So I downloaded the Windows version, generated the XML file and filtered it by vertical monitor and original games.  The plan is to then work through that list and try to figure out what works and what doesn't.
     
    There are 700 games....  this might take a while...
     
  12. EricBall
    This is the result of think exercise to design a 2-D GPU similar to those used by 4th generation consoles (e.g. SNES, Genesis, TG16) but at HDTV resolutions.  Rule of thumb is to make it easy to program (i.e. minimum updates), while still being flexible.
     
    Output is 1280x720 @ 60fps.  For reference, this has a 22.2usec line interval and 30 lines of VBLANK.
     
    GPU contains internal 2.5Kbyte RAM for two 1280 x 8 bit line buffers (one is written while the other is read), reset to $00 at start of line.
    GPU contains a single 256 x 24 bit CLUT (16 palettes of 16 colors, 24 bit RGB).  
     
    GPU is connected to 1Mbyte 10ns RAM addressed as 8192 pages of 64 x 16bit words.  (Note: for sanity all data is little-endian, so bit 0 of byte 0 is bit 0 of word 0.)  GPU RAM is copied by DMA during VBLANK (up to 1024 pages per frame).  Page $0000 is typically set to all $0000.  DMA to pages $1FF8 - $1FFF also updates GPU registers / CLUT.
    GPU registers: $1FF8 [0..47] CLUT [0..31] stored in packed format $1FF8 [48..51] layer register [0..3] $1FF8 [52..63] not used $1FF9 [0..47] CLUT [32..63] $1FF9 [48..55] offset register [0..7] $1FF9 [56..63] not used $1FFA-F [0..47] CLUT [64..255] (32 entries per page) $1FFA-F [48..63] not used layer register [0..12] Zone list starting page number [13] not used [14] color 0 is 0=transparent, 1=opaque (taken from CLUT by palette) [15] zone type is 0=sprite, 1=tile offset register [0..7] signed Y position offset [8..15] signed X position offset Rather than have a single table of sprite positions etc,  the GPU has 4 independent layers.  Each layer is described by a list of zone entries.  Each zone entry points to a list of tiles or sprites for 1 to 16 lines.  While this is more complex from a game programming perspective, it adds significantly more flexibility and dramatically increases the number of sprites the GPU can display.
     
    The offset register is used to shift the position of multiple sprites by the same amount.
     
    A single sprite / tile graphics block is 16 x 16 pixels and 4 bits per pixel, which is exactly 64 x 16 bit words = 1 page.  Color 0 is either transparent or opaque depending upon the layer register.  Pixels are stored in little endian raster order (i.e. bits 0..3 are top left pixel).
    Tile Zone entry (48 bits / 3 words each, list may extend over multiple pages) [0][0..11] Tile List page number [0][12..15] 16 - number of lines in zone [1][0..11] tile graphics block offset [1][12..15] start line [2][0..3] start pixel [2][4..9] start tile (word offset of first tile in Tile List page) Tile List entry (16 bits / 1 word each, list may extend over multiple pages) [0..11] graphics block index (added to graphics block offset to give page number) [12..15] palette If number of lines in zone + start line > 16 then next graphics block will also be read.
    Sprite Zone entry (32 bits / 2 words each, list may extend over multiple pages) [0][0..11] Sprite List page number [0][12..15] 16 - number of lines in zone [1][0..11] sprite graphics block offset [1][12..15] not used Sprite List Entry (48 bits / 3 words each, 21 entries = 1 page) [0][0..9] y position (0 - 1023 w/ wrap around 1023->0, 0 - 719 onscreen) [0][10..12] offset register number [0][13..14] y size - 1 (16,32,48 or 64 pixels high) [0][15] y flip [1][0..10] x position (0 - 2047 w/ wrap around 2047->0, 0 - 1279 onscreen) [1][11..12] not used [1][13..14] x size - 1 (16,32,48 or 64 pixels wide) [1][15] x flip [2][0..11] graphics block index (added to graphics block offset to give page number) [2][12..15] palette Graphics blocks for sprites larger than 16x16 are addressed sequentially in raster order
     
  13. EricBall
    One side effect of trying to install SteamOS is realizing doing the base install & updates while hardwired is a pretty good idea.  However, I did take the advice of JayZ and disconnect the PC from the network for the initial install to avoid having the Admin user tied to an email address.  I've also created individual normal users for each member of the family.
     
    The actual Windows 10 install & update went smoothly. 
     
    Then came the big test - I installed Steam, CS:GO and did the timedemo.  Unfortunately with the default "high" settings I didn't hit my desired [email protected] target (although I did get over 120Hz, and significantly better than the sub-60Hz I got on the iMac at low settings.  The bottleneck appears to be the graphics card as it's pegged to 100% and none of the CPU cores are.
     
    On the one hand I'm disappointed with the result - although it's not like I had any real reason to expect it would meet my target out of the box.  Rather than throwing money at the problem and spending hundreds more to get higher performance I went with the CPU & graphics card with the "best bang for the buck" - which means both cheaper and lower performance.  But I am kicking myself for not going with the GeForce GTX 1660 Super.
     
    But I've done some more testing and I can get over 170Hz by dropping the quality settings, so now I just need to decide which is more important - pretty or fps, and see which settings get me the most fps for the least visual impact.
     
    And it's not like it's difficult to upgrade the graphics card if I decide in 6 months I really want to spend the $$.
     
    Now begins the long process of setting up the various programs I want to use on the new PC, configuring them to work the way I want, and consolidating the files from the iMac and my work laptop.
     
  14. EricBall
    lep20061108.zip
    Okay, I've fixed the look-ahead bug which was causing the ladder issues vdub_bobby was noticing. I think you'll find the leprechauns to be a little smarter now. Leprechaun Level Editor updates as usual.
     
    Oh, one note. The AI for swinging on ropes is the same as running with the one exception of falling when the player is directly below. (Note - it may be possible to run under a leprechaun and not trigger this behaviour.) So when the player is higher than the leprechaun they will do look-ahead drop-off detection at the end of the rope & automatically reverse direction and go into hunt mode.
  15. EricBall
    YouTuber Tom Scott has just released a 16 episode series on making an app.  (YouTube link behind the Spoiler.)
     
    I haven't watched the series (although I will), but IMHO the first question you need to ask yourself is what it's going to cost on an ongoing basis and how you plan on paying for it.
     
    For Slide Tilt Roll, the only ongoing costs were my Apple Developer ID* and a small website & domain name**, but something like Tom's failed messaging app is going to require some kind of server which will need to scale with the number of users along with ongoing support for users.
     
    In addition, you want your revenue to match your costs.  e.g. When I first came up with the idea for Slide Tilt Roll and the built-in level creator I had the idea of having a website forum which players could use to share levels - a forum which would cost money to be member.  But after some thought I discarded that idea because the revenue model (paid membership) didn't match the expense model (server & bandwidth costs).
     
    * I've let my Apple Developer ID lapse, so Slide Tilt Roll isn't on the App Store anymore.  While the cost of the ID isn't much, the bigger problem is Apple requires apps to be updated.  In my case that would mean upgrading to the latest MacOS, XCode & Swift and then rewriting my OpenGL fragment shader to Metal (in addition to any changes for the current version of Swift & iOS frameworks).  Too much work for very little payback.
    ** I've since discovered it's nice to have a personal domain so I can create email IDs.
     
  16. EricBall
    Valve decided to make CS:GO free to play and at the same time add a battle royale mode "Danger Zone". This is great for me as I was looking for a way to scratch my PUBG itch on my 27" iMac rather than playing PUBG on phones.

    But IMHO Danger Zone is better than PUBG because it is only 16 players on a correspondingly smaller map. This leads to quicker, more intense gameplay and shorter games.

    With PUBG, I typically spent the first third of the match (10-15 minutes) looting up, the second third traversing the map or camping depending upon where I am relative to the zone, and only the last third actively looking for conflict with the remaining players. Danger Zone basically trims down the experience, speeding it up and pushing the game into the conflict interval very quickly.

    Other players may "drop hot" and thus spend the beginning of their PUBG game simultaneously looting and in conflict. Even those players should enjoy Danger Zone as it ensures all players are relatively close. They could even select a drop point specifically near other players. The tablet map also makes it more difficult for players to camp & hide.

    The other game design decisions (e.g. money, buy menu & delivery drone, loot in cases, map showing player occupied hexes, drop point selection & how ammo works) can all be learned and tactics modified or developed. None of them make the game unplayable. (And I believe some are even shared by other Battle Royale games, like Ring of Elysium.) Even the lack of lean, crawl & vault aren't deal breakers. And while I've heard complaints that the Source engine is showing it's age and the map is unremarkable, I don't find DZ to be lacking in either case.

    Obviously Danger Zone isn't for everyone. There is no third person perspective, so players who like to peek corners are out of luck. "Skins" also don't include the player model, so players who like to play as team mascots or naughty nurses are SOL.

    The one place I do believe DZ could improve is with the matchmaking process. Currently it appears the game requires all 16 players to Accept before the "waiting room" is started. If even one player doesn't click the Accept button before the 20 second countdown, all players are put back to the matchmaking process. (If a player disconnects after the waiting room has started, the game still continues.) IMHO this is stupid and results in a lot of delays. My suggestion is to start the "waiting room" if a minimum number of players have accepted (e.g. 12). Then while those players are preloading the assets and playing a 2 minute deathmatch, the matchmaker selects other waiting players to fill the game. If they click Accept, they are put straight into the waiting room. Once 16 players are in the waiting room, or after 2 minutes, the main game begins.
  17. EricBall
    I've been feeling minor PUBG withdrawal since my son took his Samsung tablet to college as I'm unwilling to spend the $$ to buy my own tablet for a "free to play" game. Last night i broke down and installed Fortnite on my 27" iMac. I've played about a dozen games so far and noted the following differences:
    The big one is the whole building mechanic. It's hard! I'm not sure I have the free time to be more than a noob. I'm certainly not expecting to win any time soon. Unlike PUBG, it looks like it's going to take a lot of play time to expand beyond the default skin(s) (as I have no intention to spend $). It's also interesting that there is (apparently) no way to even select which default skin you play with. It definitely marks the difference between the payers and the freeloaders. Ammo seems to be less common in Fortnite than PUBG - in PUBG I never ran out of ammo while playing solo, but in Fortnite I don't seem to have enough. Weapon accuracy seems to be much lower in Fortnite, at least for ARs & SMGs; although I might get better with practice. This probably also increases how much ammo I'm using. Fortnite has a lot more weapons than PUBG, but no attachments. So scoped weapons are much rarer in Fortnite. And while higher level weapons typically do more damage, that's not always the case. Consumables like grenades and health packs take a carry slot in Fortnite, so whether to pick them up becomes a trade-off decision. Health packs also seem to be rarer in Fortnite. Maybe it's my level, but players seem to die a lot quicker in Fornite. Half of the field is eliminated before the first circle has completed.

    Given my current abilities, I'm going to define "fun" in terms other than placement and winning. It is an amazingly diverse environment, so right now I'm just having fun exploring.

    2018-11-23 I've put up a short video of me taking down a better player:


    And a couple of complaints: The MacOS client crashes occasionally (although only in the lobby, not in game). I also takes a long while to start up. The logs I've seen have errors relating to my en_CA locale. Some lobby actions change the game mode from Solo to Squad. And because I have it configured for "No Match" (so I can go in the practice area by myself), I won't realize it until I get slaughtered by a squad.


  18. EricBall
    Via one of the guy's YouTube videos, I happened across http://www.the8bitguy.com/2576/what-is-my-dream-computer/

    Now, not to rain on anyone's parade - but retro dream computers are just that, dreams.

    I've been playing with computers since the Apple ][+ days - so I've got plenty of nostalgia for retro computers. But guess what, when my parents gave me a TRS-80 Color Computer as a gift a few years ago, I wondered why they bothered.

    Sure, it's the computer I had in my teens and I've got a lot of great memories of it. And it's got a decent built-in BASIC. But there's no point. Emulation is good enough if I ever decide I want to spend time reliving those memories.

    The problem gets worse for a hypothetical dream computer as there is no existing software, and there just wouldn't be enough people interested in creating software for it. Sure you could spend time creating another Pac-Man or Super Mario Bros. clone. Or you could just load up an emulation of the original.


    Of course, it's fun to dream. Just don't expect them to come true.

  19. EricBall
    Earlier this month the family and I spent a week camping at (nee Six Flags) Darien Lake - riding roller coasters & other rides plus roasting marshmallows & drinking beer. Every night DL has a laser & fireworks show set to music. (Unfortunately the same one every night.) The laser show part of the show in particular was particularly impressive and would have made Pink Floyd (from 40 years ago) green with envy - complex animated scenes in full color. (Probably restricted more by the creation tools and software capabilities than the actual hardware.)

    But seeing what a modern laser projector is capable of got me to thinking - could one be used as a replacement for a vector monitor (e.g. Asteroids and Tempest)?

    But then I suspect was others probably had had the same thought - and there's probably a big reason why I've never heard of a laser version of Tempest. Of course, last week's insurmountable problem might be this week's trivial solution. So I started with a little investigation.

    To make a long story short, the limiting factor is moving the beam. A vector monitor uses electromagnets, while a laser display uses mirrors - typically using a variation of a "mirror galvanometer" or galvo. People have made their own galvos using the voice coil actuator from a hard disk (which is what moves the heads across the disk). But electromagnets can change the position of the beam from one side of the monitor to the other in 100-300 microseconds, whereas it requires 10-20 milliseconds to move the head across the entire disk. That's 100 times slower and a bigger challenge than I think can be easily overcome.

  20. EricBall
    https://itunes.apple.com/us/app/slide-tilt-roll/id1366633420?mt=8

    I took a day off so I could finally put on my "round-tuit" and get my iOS game into the App Store.

    100% free to play. No in-app purchases. No subscriptions. No advertising. WiFi not required. 30 levels to complete (so far) Built-in level creator with the option to submit levels for inclusion in future updates. Requres iOS 9 or better, compatible with all devices


  21. 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.

  22. EricBall
    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).



  23. EricBall
    Ingredients:
    Bought: Raspberry Pi Zero W, Pro: cheap at C$13.50 (+tax & shipping, case C$6), tiny (65mmx30mm), low power (powered via USB on TV), WiFi & Bluetooth (for controllers). Con: can only handle 8 bit & 16 bit gen consoles, miniature connectors require special cables (C$6)
    On-Hand: 4GB micro-SD card, HDMI cable (dollar store), micro USB cable (for power), PS3 controller
    For initial set up: PC (downloads etc), USB keyboard (to set WiFi passphrase), mini USB cable (for PS3 controller pairing),

    I decided to use Lakka. The other popular option is RetroPie. However, both use RetroArch / libretro for the actual emulation (which is also used by a lot of other current non-PC emulator suites). Lakka is done by the same people as RetroArch and seems to have a minimalist ethos; which I tend to prefer. RetroPie can do more than just RetroArch, but I've read that makes configuraton more complex.

    Getting the system up and running was a little rocky because the battery on the PS3 controller was dead - which made me think it wasn't connecting via Bluetooth. Before I realized that I charged up my son's 8bitdo NES30 Pro controller and got it connected - although that required SSH-ing into the box.

    Then it was a simple matter of loading up some Vectrex ROMs (which are usable legally), clicking "Scan" and then playing some rasterized vector games.

    The scanning process uses the No-Intro ROM database and automatically determines which console each ROM is for then puts them into a single list by platform. While uber-simple it does cause some issues, IMHO. The No-Intro database limits itself to perfect images of the commercial releases. So while this does exclude the huge number of hacked ROM images which other ROM sets include, it also excludes homebrews. It may also cause frustration if the easiest to find ROMs for a game aren't in the database. It also lacks any kind of organization - a must when several consoles have over a thousand titles.

    I started by hauling out my external backup drive and started to search for the ROMs I snarfed from USENET 25 years ago. I then took the original yencoded messages, dumped them in almost 100 separate directories (to avoid possible name collison) and extracted the files. After clean-up, I had some 6000 archives with over 9000 files. Fortunately, I was able to use clrmamepro to load up the No-Intro database and use the Rebuild function to scan through those archives for any matching ROMs and re-archive them to files usable in Lakka. (Unfortunately this requires about an hour per platform.)

    Of course that still leaves me with several thousand ROMs (although I'm missing some notables as my collection is mostly pre-1993). My solution is to use Wikipedia's lists of best selling video games to pull out the most popular titles and do some additional pruning by language and to remove duplicates.

  24. EricBall
    As my wife often reminds me, I have a habit of not finishing projects once I've started them. (Usually while pointing at one of them.) I have to say that I've gotten better at managing this habit (although not necessarily at finishing projects). I try not to start projects, or at least start spending money instead of just time, unless I have a relatively clear understanding of what it's going to take to finish the project (and why I'm bothering). But i still have quite a few projects hanging around, most with little hope of ever being finished.

    One of those is the Tempest MAME project which started in 2004 when I rescued a Tempest cabinet from the curb. It's actually far closer to completion than many of my projects, i.e. requires more time and effort than money to finish.

    But now there's a guy who might be interested in buying it. While my wife would probably be willing to give it away just to get it out of the (unfinished) basement, I'd probably want to get more than "Twenty-eight dollars and fifteen cents." (obscure song reference), I'm not sure how much it's actually worth (or worth to me). Hell, just the control panel is probably worth a couple hundred dollars on eBay (although I suspect that's 90+% of the value of the whole shebang).

    Real life ain't like American Pickers - more like those LetItGo commercials.

    But there ain't no way I'm going to haul it out of my basement and deliver it. You want it, you gotta come and take it - and bring your own crew and equipment.

  25. EricBall
    https://arstechnica.com/gaming/2017/06/sega-forever-emulation-performance-problems/

    For some reason I've never gotten into Sega's consoles. Sure I've played Sonic, but that's about it. However, when I heard about Sega Forever, I thought I might give it a try - watch a few ads, play a few games. But now I probably won't bother.

    The question for me is why Sega would release anything less than perfect. I have to conclude the decision makers at Sega don't care about their games, only about making money. Not to say that making money isn't important for a company, but I suspect Sega Forever will make less money than if they spent more money to release a better product. Instead of engaging players so they play more, and thus watch more ads, this poor product (with apparently heavy advertising) is more likely to turn players off - resulting in higher short term gains, but very little long term returns.

    I also suspect the difficulty of emulating consoles is not appreciated. The primitive CPUs and GPUs were tightly coupled and many games exploited this via cycle counting techniques. Reproducing this relationship, especially in devices which can vary considerably. Plus there's no easy way to "scale down" for lower performance devices.

×
×
  • Create New...