Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Jonathan Cauldwell

79
Posts
744
Followers
2
Following
A member registered Feb 03, 2014 · View creator page →

Creator of

Recent community posts

It's not abandoned but I have been working on other projects.  It will be updated at some point.

It's fantastic to see the games you have created this year, well done everyone!

Being a coder is a little bit like being Harry Potter, only for real.  Writing code is like writing a magic spell.  We can write a few lines and suddenly we can make a kangaroo jump over barrels, a ball fly into the back of a net or a helicopter rescue people trapped near a volcano.  We can create any world and make anything happen in code.  We are all wizards, we all have magical powers when we can code and we can spread magic with our imagination.  Thank you for using your imagination and creating your magical games.  I hope that some of you will consider writing software as a career, it's absolutely one of the very best jobs; it's every bit as good as being a wizard.

Barnsley?  LOL

MPAGD runs on Windows.  AGD runs on the ZX Spectrum, so you would need an emulator for that.

It isn't designed for turn-based games but I think they should be possible.

Off the top of my head I'm not sure what the problem is.  If you post on the forums maybe someone who has had a similar issue will remember what the solution was.

No, it wouldn't be straightforward to do that because the extra RAM is banked.  MPAGD would have to spit out multiple listings and the user would have to manually assemble them individually then save them out as multiple code blocks, not to mention writing a BASIC loader program with some machine code to load the code files into the relevant RAM banks.  Anyone capable of doing that is already capable of taking the existing assembly language listing and modding it to use the extra memory.

Haven't tried it.  It would be difficult to play if it does, the screen display would be a mess.

We have engines and compilers for Z80, 6502 and 6809 machines so it's probably an idea to start with one of the 6502 models.  Modding the compilers is probably the simplest job, that's written in C.  The engines take a bit more converting, obviously the way sprites and display routines are handled differ tremendously between formats.  Kees van Oss did the Z80->6502 conversion so he's the best person to ask.  He's on the MPAGD forums and in the Facebook group.  I'd be doing the Windows editors so you'd need to let me know what you want and how you want graphic data output for the compiler.  The best place to chat about all of this might be Facebook

Not yet, we're still looking for a C64 expert to convert the engine and make the few necessary mods to the compiler (easier than it sounds).  I'm always happy to work with a volunteer, add the editors to the Windows tool and output the graphics in the required format.  Likewise for any other machines.

The Chroma looks okay but it's still using Sinclair characters.  Go to the Control menu at the top, and select "Enable Quicksilva Character Board", then re-load the game.  That should fix it.

I don't recall off the top of my head but there should be a couple of batch files within the "Suite ZX" subdirectory, one called build.bat and the other export.bat.  If you look in there you should get an idea, you can even modify them to copy the .tap anywhere you like for convenience.  If you have any further questions they're probably best answered over at the AGD forum.

I remember playing this when it was first created, simply glorious to see it here and to read that it works on Windows 10.  Just downloaded and will have a play with it when I get a chance.  Thank you!

Not at present, but we are always looking for volunteers to convert the engine and compiler to more machines.  Do feel free to bring this to the attention of developers in any retro forums you visit!

It should run on 32 and 64-bit Windows so give it a go

Thank you, I hope you have fun with it and get to create an 8-bit game.  MPAGD is designed so that the user can create games regardless of programming experience.  It can create the initial scripting code for you, which can be amended later when you feel confident enough to make changes - small at first, bigger changes later on.  As your experience grows you'll start to realise just how powerful the tool is

At present I don't know of anyone working on a C64 compiler or engine so feel free to make a start.  The best place would be with the compiler and engine for an existing 6502 machine; Kees van Oss did the initial Z80->6502 conversion work so he's the best person to talk to about that.  You'd also need to tell me about the graphics format you want so I could update the Windows editor and output data in the correct manner for the compiler/engine to use.

Yes, it's a known issue

It's still a live project as far as I'm concerned

It uses a lot of Windows system calls so no Linux version.  Sorry

Yes, there is a comprehensive manual in the download.

Yes, it is still in development

There is a program to do that, there should be some posts about it at the AGD forums.

If you have MPAGD then take a look at EngineZX.asm then search (if memory serves) for "cang" as those routines check if a 16x16 sprite can move in the 4 directions.  It's all commented.

You should display the text on screen yourself using messages.  There's also a WAITKEY command that will just wait for a keypress and won't set the controls

Briefly, check that you have put a player sprite in your preferred re-spawn position on every screen on which the player might die.  If that doesn't work, post on the AGD forums with a little more detail

AGD has a CONTROLMENU command that waits for the player to press 1, 2 or 3 and sets the controls to keyboard, Kempston or Sinclair joystick accordingly

the BEEP command creates beeper effects.  It should all be explained in the AGD documentation

It's a file that when loaded into an emulator loads and runs the game.  If you wish to play a game on a Spectrum emulator you usually load .TZX or .TAP files

Screen characters are formed by a collection of 8 bytes, 256 bytes apart from each other.  One simple way is to have a "character map" of 768 bytes (32x24) in memory to store the characters at each screen location, then the colour attributes would not matter.

AGD supports 16x16 or 16x24 sprites.  For anything else you'll need to use more than one sprite whether in AGD or MPAGD

Yes, there's an option to create a .TAP file

Not at present although it would be perfectly suited to that machine.  We'd need a volunteer to convert the compiler (relatively straightforward) and engine (requiring a TI-99/4A expert).  I'm always happy to help if anyone wishes to step forward.

Once you've opened the lower screen for printing, make sure you reset the cursor position to the top left.  Printing chr$ 22, chr$ 0 and then chr$ 0 will do that.  Then you should be able to put another 64 characters in the bottom panel.  Don't go beyond that or that part of the screen will scroll up

I don't understand what you're trying to do.  If you want to scroll the screen just call the ROM routine at 3582

When using the ROM routines you need to open the channel to display things on the bottom two lines.  Putting 0 or 1 into the accumulator and calling 5633 will do the job.  When you want to display on the rest of the screen, call 5633 with 2 in the accumulator.

Yes, that's the way I have always written games.  X is the distance from the top of the screen, Y is the distance from the left edge.  I usually put comments in to warn people that's how my routines work

No plans at present.  Unfortunately it has to use a lot of Windows system calls

A while ago I was thinking about adding an import/export option via a SCREEN$ file if that would be useful?

Yes, if we can find experts on their machine who are willing to convert the engine and compiler.  Help and advice is not far away, the engine is fully annotated and the compiler is written in C so only requires a few simple changes.