Jump to content

haroldoop

Members
  • Content Count

    101
  • Joined

  • Last visited

Community Reputation

27 Excellent

About haroldoop

  • Rank
    Chopper Commander
  • Birthday 09/10/1979

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Brazil
  1. You may want to take a look at "The Pac Man Dossier", specially chapter 6 and chapter 7 You may also want to take a look at the making of Planet X2
  2. In my opinion, the best classic console to develop for would be the Sega Genesis/Mega Drive, due to its fast CPU and flat address space (no need for bankswitching). https://stephane-d.github.io/SGDK/
  3. Probably not, as the original itself was coded in assembly; the options would be to either write a clone from scratch or create a hybrid by reusing just the kernel and wrap it in batari BASIC.
  4. The entries for the SMS Power! Coding competition 2018 are now available. There are less Coding entries than in the previous years, but what's there, is quite nice. http://www.smspower.org/forums/f9-Competitions
  5. haroldoop

    SID chip?

    Probably not; someone would have to design a way to connect a SID chip to the 2600, and then someone would have to create a kernel to communicate with that.
  6. Great job so far! It seems to be a pretty cool project. Yes, there are native players for both Ogg and XM formats, though I haven't been able to experiment with them yet. Also, there are quite a few sound players for the Sega Genesis; in theory, some of them should work on the 32X, too, though it would be necessary to implement a communication layer so the SH1 CPUs could ask the 68K CPU to play the music. As for ABC music, one possibility would be to use some MML Compiler, since MML syntax is very similar to ABC.
  7. Version 0.10.1 is now available: Product name string on the ROM header changed to "Powered by BlocklyVN32X"; Generated ROM will be automatically padded to 256KB, 512KB, 1MB, 2MB, 3MB or 4MB (that is, 2, 4, 8, 16, 24 or 32 mbits). Release page: https://github.com/haroldo-ok/BlocklyVN32X/releases/tag/v0.10.1 Portable version: https://github.com/haroldo-ok/BlocklyVN32X/releases/download/v0.10.1/blocklyvn32x-portable-0.10.1.exe
  8. Thanks! That game has a pretty interesting concept, not to mention a quirky sense of humor.
  9. Congratulations, that looks pretty cool so far! Well, the IDE just generates C code and then invokes a Makefile to compile it, so it would be mostly a matter of: Porting the support C libraries for the target hardware; Setting up a few command line image conversion utilities to convert the PNG images to a format that can be used on the target hardware; Creating a Makefile that will call the image conversion tools and compile the C file. Also, it the compilation requires the generation of some source files besides the C file that is already generated, Blockly's API also makes it relatively easy to do so.Essentially, it shouldn't be incredibly difficult to coerce the tool to output binaries for other platforms, as long as the hardware is sufficiently capable, and there is a C compiler available.
  10. Version 0.10.0 is now available: Added command to choose the name that will be displayed in the top left corner of the text window; Resolved the input lag problem on the generated ROM. Release page: https://github.com/haroldo-ok/BlocklyVN32X/releases/tag/v0.10.0 Portable version: https://github.com/haroldo-ok/BlocklyVN32X/releases/download/v0.10.0/blocklyvn32x-portable-0.10.0.exe
  11. Blockly itself could run on any browser, but BlocklyVN32X depends on electron. It would be possible to refactor the code so that it could run as a web application, but it would take a while. I once thought whether or not it would be interesting to be able to import/export to twine or inklewriter; maybe that idea could be revisited; it would be far from a perfect process, but it could be useful. Looking at the source, it does not look very difficult to implement. Perhaps I could add it as a no-op, initially, and then add the appropriate block to the IDE. That would be a nice compromise, since there's no import function.
  12. Yes, Blockly's interface can become confusing for large projects. In BlocklyVN32X, I tried to make the clutter more maneageble by creating an "Overview" tab that shows a Zoomed out version of the current workspace; clicking on the zoomed out blocks navigates directly to the corresponding actual block. There's also an experimental search panel on the overview tab; it looks ugly, right now, but it sorta works. Even then, being able to divide the project into smaller pieces would certainly be a more scalable solution. I have 2/3 of an idea on how to implement that. Another alternative would be to use Blockly's own API for the task; if you take a look at '/blockly/generators/arduino.js', in the declarations of 'Blockly.Arduino.finish', 'Blockly.Arduino.genIncludeMk_' and 'Blockly.Arduino.genImages_' you can see how the sources are generated. The string returned by 'finish()' is what goes to the C file. Additionaly, in BlocklyVN32X, whatever gets included in the 'Blockly.Arduino.otherSources' object gets written as an additional file on the 'generated' dir.
  13. Well, for retro platforms, the music/SFX would have to be platform specific, anyway, so I see no problem. Sounds like a nice idea! If you're using the "portable" version, and are running on Windows, it should compile for 32X right out of the box, with no additional setup required; it comes with everything included. For Linux, well, the IDE will run, since it uses electron; on the other hand, compiling the ROMs won't work quite right, since it invokes a few command line applications, and I hadn't had time to set up the compilation to work on Linux, too. On Android, well, it would be more complicated, since there's no official electron version for it. Perhaps it would be possible to modify the editor so that it would be run on either electron on Cordova, depending on the platform; making the compiler run on Android would be an additional challenge. Yes, it seems the XML is being saved with the full paths to the images; the editor automatically corrects the paths on loading, but it would be indeed nice to save them correctly in the first place. I have opened an issue on the repo. Whoops, it seems that I kinda missed that detail. It always displays "Test". I opened an issue on that. WishingWell.png and spacecabin.png seem to actually be a JPEG files; reimporting them inside the "Background" tab seems to correct the problem. Android.png is too big to fit the 32X screen, and has no transparent background. Editing the PNG to add transparency and reimporting it in the "Portraits" tab seems to correct the problem. Also, there seems to be a bug on the code generator that makes it generate two "vn_start()"s if there are no loose blocks. Renaming the label "start" to something else and then creating a loose block that just jumps to it sorta gets around the bug until the code generation can be fixed. Here go the fixed project, plus the compiled ROM. karri-test-compiled.zip karri-test-project.zip
×
×
  • Create New...