Jump to content

intvnut

Members
  • Content Count

    3,611
  • Joined

  • Last visited

  • Days Won

    7

intvnut last won the day on December 27 2016

intvnut had the most liked content!

Community Reputation

2,682 Excellent

3 Followers

About intvnut

  • Rank
    River Patroller

Profile Information

  • Gender
    Male
  • Location
    @R6 (top of stack)

Recent Profile Visitors

19,732 profile views
  1. Why isn't there an if-statement around this? if onland = 0 then if santay=80 then onland=1 : goto toporbottom if santay=17 then onland=1 : goto toporbottom end if Granted, you will need to move where you set onland = 0 up slightly. Also: Remember hardware collision detection has a one or two frame delay, depending on your perspective. Frame N-1: compute MOB positions for frame N. Frame N: MOBs are displayed, collisions computed. Frame N+1: game gets to see the collisions for positions it computed in frame N-1. I don't know if that factors into your issue as well, since you're combining your current notion of X/Y with the collision information from a previous frame. I haven't looked at the .bas file yet. I don't think my phone lets me do that easily.
  2. @Carl Mueller Jr's DOS based emulator (INTVPC) and dev kit ran just fine on high end 386 and 486 hardware, from what I recall. (Not sure if it pulled a full 60Hz on 386s.) It directly made use of the VGA's unchained planar memory mode (look up "Mode X") to get hardware pixel doubling for free as well. That's still a notch above XT/AT class, though. His assembler would likely move easily to anything Turbo Pascal can compile for though. jzIntv and even as1600 probably don't scale down that far at this point. I'd have to take some effort to trim the fat that's accumulated over 20 years. Don't get me wrong: jzIntv is quite fast, but it's quite fast using techniques suited to modern hardware. AS1600 has gained a bunch of features, but at the expense of memory bloat. I've focused increasingly on making the modern experience reasonable. @Carl Mueller Jr has taken Intellivision emulation to even smaller environments as I understand it. I'll let him talk about those if he wants.
  3. Also: There's no reason to limit yourself to one file in the per-configuration directory. If you have multiple pieces that you need to tweak differently in this way, you can do that with each of these pieces. Make separate versions in the separate cfg_XXX directories.
  4. One trick I've used with AS1600 is to abuse the "include path" to point it to different directories to get different build configurations. You could do something similar with IntyBASIC's library_path argument. Make a directory for each of your game configurations, e.g. cfg_1up_easy, cfg_1up_hard, cfg_2up. Copy intybasic_prologue.asm and intybasic_epilogue.asm into all of them, since it appears IntyBASIC only searches one directory. (Someone correct me if that's not true.) Add a .bas file in each that holds the configuration-specific details. (Note: This can INCLUDE other files!) For example, name it game_config.bas. In your main game source file, simply INCLUDE "game_config.bas" (or whatever name you chose). When you compile the game pick the configuration by specifying one of the directories created above as the library_path. The following will compile the three versions to three separate assembly files: intybasic --title "My Game (1up Easy)" mygame.bas mygame_1up_easy.asm cfg_1up_easy intybasic --title "My Game (1up Hard)" mygame.bas mygame_1up_hard.asm cfg_1up_hard intybasic --title "My Game (2up)" mygame.bas mygame_2up_hard.asm cfg_2up Then, assemble these as usual. You could fold the details into separate scripts/batch files, so you can run, say, build_1up_hard to just build that variant. As I said, I've used this to build variants with different features (debug code, cheats, etc.) w/ AS1600 and its -i dir flag. I see no reason why a similar trick couldn't work with IntyBASIC.
  5. To be clear, that's jzIntv's compilation time. SDL2 actually compiles faster, but they don't enable link-time optimization, and that's somewhat expensive.
  6. You don't need to build jzIntv as root. Just plain ol' make (or better, make -f Makefile.linux_sdl2) should do It looks like whatever you used to unzip jzIntv didn't apply the "execute" bit to the scripts in src/buildcfg/, based on this part: make: execvp: ./buildcfg/svn_rev.sh: Permission denied make: execvp: ./buildcfg/svn_dty.sh: Permission denied To fix that, run chmod +x buildcfg/*.sh from within the src directory. For the rest: jzIntv does not build or install SDL2 for you. You'll either need to install the SDL2 devel package for your Linux distro, or compile and install SDL2 yourself. On Ubuntu 16, sudo apt-get install libsdl2-dev should do the trick. I'm pretty sure installing the "dev" package pulls the main libraries. If not, sudo apt-get install libsdl2 gets the run time libraries. The advantage of compiling and installing SDL2 yourself is that you'll get a newer SDL2. According to this page, Ubuntu 16.04LTS defaults to 2.0.4, while the latest is 2.0.12. For SDL2, IIRC, you can install it with something along the lines of: (From within the SDL2-2.0.12 source top-level directory) $ ./configure --prefix=/usr/local ... lots of configuration goes by ... $ make -jN ... lots of compilation goes by ... $ sudo make install In the sequence above, replace "N" in make -jN with the number of CPUs you have, or a smaller number. For example, if you 4 CPUs, make -j4 works reasonably well. You can use Make's -j flag when building jzIntv as well. On my 4 CPU Linux box, make -j4 brings the compilation time down from about 3 minutes to about 1 min 20 seconds. BTW, I did a partial release the other day, to incorporate some bug fixes from July. You can grab that source here: http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200822-src.zip Once I get a chance to build R-Pi and Linux builds, I'll make it the official release. The bugfixes are fairly minor.
  7. If you recorded an AVI, I believe jzIntv shouldn't drop any frames in the AVI itself. If you're seeing frame drops in the AVI, let me know. As for the actual display, I seem to get more consistent display synchronization in full-screen than in windowed mode. Also, SDL2 is lightyears better than SDL1 so far in my experience.
  8. Nothing comes to mind other than 1979 was the introduction of the system. IIRC, it was test-marketed at the end of 1979.
  9. Wow, a board with 1979 ROMs, but no RF shield. (7947 is the date code: 1979, work week 47.) Somewhere in my storage unit I have a few dozen bare boards. If I come across them, I'll try to remember to photo them for the PCB database. Are you also cataloging the ROM numbers you find? e.g. RO3-9504-107 / RO3-9504-207? The 3-digit code identifies the contents of the ROM. And yes, SYL is likely Sylvania. Makes sense as they were an early manufacturing partner.
  10. If you're developing a game that relies on the ECS from IntyBASIC, then end users can use either the phony ecs.bin I created above, or the real ecs.bin. IntyBASIC does not depend on its contents. The phony ecs.bin I created above is completely unencumbered. It's only needed for the emulator. And, in fact, I could easily tweak the emulator to not require the binary at all for IntyBASIC games that just want to use the ECS's additional sound capabilities, and possibly its extra RAM, controller, or keyboard support. For someone playing on real hardware via a flashcart, they'll need an actual ECS unit to get the additional functionality. The additional functionality isn't part of the ECS ROM. It's in the extra sound chip and RAM chip that the ECS provides. Same deal: If you're playing on real hardware, and you want ECS functionality, you need an actual ECS. So far, I believe the most popular use of the ECS is to add richer sound effects/music to games. If you design things appropriately, your game can fall back to simpler sound effects and music when the ECS is not attached. That way, folks with an ECS get enhanced capability, and folks w/out an ECS still get to play. That's what I did with Space Patrol, for example.
  11. Next to wherever you have exec.bin and grom.bin. I haven't looked at the IntyBASIC SDK, so I don't know where it puts those.
  12. IntyBASIC brings too much baggage—the prologue/epilogue code. Just assemble this as ecs.bin: ORG $1000 ; this value is unimportant. REPEAT 12*1024 DECLE -1 ENDR That's it. You can discard the ecs.cfg that AS1600 will generate. It's garbage and it's not needed. Feed the ecs.bin file to jzIntv, though, and homebrews should start working.
  13. Once upon a time, I created a file with 24KB of 0xFF bytes as a dummy ecs.bin. This is sufficient to get homebrews running that just want the extra PSG and/or RAM. I think there's still copies of it floating around, as every so often I see a bug report that involves trying to use it with one of the original ECS games. I suppose if it makes sense, I can add a "ECS lite" mode to jzIntv that skips loading the ECS ROM image. With a small tweak to IntyBASIC, it could even tell jzIntv to fall back to that mode if ecs.bin is unavailable.
  14. I suppose an ON GOTO or ON GOSUB might be easier to read than IF THEN ELSE in some cases. Probably also marginally cheaper if done right.
×
×
  • Create New...