[Help] Game engine written in assembly language and other questions

[starwindz]

I am currently studying the assembly language using some books such as 'Atari Roots - A Guide to Atari Assembly Language' to make games in my spare time. I have several questions about this.

 

1. What is your development environment? (OS, Editor, Compiler)

 

2. Are there any kind of game engines written in assembly language such as MADS?

(Graphics initialization, sprite, sound, joystick engine and etc...)

 

3. What are the sprite and sound editor which you are currently using?

 

4. Recommended game source code written in assembly language to study the game development?

 

Thank you in advance.

[bob_er]

Hi,

1. I'm working under Linux with Geany (as editor) and my own buggy assembler (similar to Mads but much simpler).

2. I don't think that there is any ready-to-use game engine. No such resources on a8. Graphics routines should be fit to your requirements (colors, modes, sprites, layout, etc...). Joystick is very easy - just read proper register. Sound is supported by tracker (msx player).

3. For sprites - I created own conversion tools from PC's .TGA format (created by modern paint stuff). Sound - there are various tools. On windows is Raster Music Tracker. In my soft music is composed on A8 using Theta Music Composer.

4. IMHO - it's hard to say. All final sources are optimized - code can be hard to read. Here you have some of them: http://sources.pigwa.net/?page=3

[TMR]

1. What is your development environment? (OS, Editor, Compiler)

Crimson Editor, firing the source through Xasm for the Atari 8-bit or ACME/Pasmo for other platforms. All running on a collection of Windows XP boxes.

 

 

 

2. Are there any kind of game engines written in assembly language such as MADS?

i don't think so no, but that shouldn't be surprising; most games tend to be bespoke code tailored to the specific job, trying to produce a generic engine isn't easy in those cases. For players alone i have half a dozen different engines in my work files which are all suited to different game styles and that doubles if i add in the software sprite-based stuff!

 

3. What are the sprite and sound editor which you are currently using?

i don't do music but the tunes in my code are all made with Raster Music Tracker. For sound effects i have my own driver which is edited from source and sprites... well, it depends on the project but there's usually a bespoke bitmap to source code converter in the work folders somewhere. =-)

 

4. Recommended game source code written in assembly language to study the game development?

Nothing specific off the top of my head, but there are a few people giving out their source so search the forum and have a pick through what you find to see if there's something similar to where you want to go.

Edited November 11, 2014 by TMR

[+MrFish]

2. Are there any kind of game engines written in assembly language such as MADS?

(Graphics initialization, sprite, sound, joystick engine and etc...)

 

2. I don't think that there is any ready-to-use game engine. No such resources on a8. Graphics routines should be fit to your requirements (colors, modes, sprites, layout, etc...). Joystick is very easy - just read proper register. Sound is supported by tracker (msx player).

 

i don't think so no, but that shouldn't be surprising; most games tend to be bespoke code tailored to the specific job, trying to produce a generic engine isn't easy in those cases. For players alone i have half a dozen different engines in my work files which are all suited to different game styles and that doubles if i add in the software sprite-based stuff!

 

No, but I think there are a few generic sprite engines for tackling typical needs of games. I think MADS includes one in the distribution package for handling character (Antic 4) based softsprites. I think this was used as a basis for the game Bomb Jack/Jake, for instance.

Edited November 11, 2014 by MrFish

[MaPa]

1. Windows 7, ConText editor, XASm compiler + Altirra emulator

 

2. Don't know about any and as was already said, most of the time you will create unique engine.

 

3. All music/sfx in my prods are from Raster Music Tracker with the exception of 1k intros of course

 

4. I don't know where to find some sources. Some link to the site with some source codes was already be posted. I always release my prods with source codes too. See my signature for links to threads with source codes.

[Heaven/TQA]

I am currently studying the assembly language using some books such as 'Atari Roots - A Guide to Atari Assembly Language' to make games in my spare time. I have several questions about this.

1. What is your development environment? (OS, Editor, Compiler)

OSX & Windows 7 using WUDSN IDE and MADS for Atari and DASM for VIC20/C64

WUDSN has anything check out: WUDSN.com

2. Are there any kind of game engines written in assembly language such as MADS?

(Graphics initialization, sprite, sound, joystick engine and etc...)

as TMR said... tons of different... but most are tailored to a specific task and game... so I would call that more routine library.

3. What are the sprite and sound editor which you are currently using?

G2F, sprites were done on high level (Photoshop, GIMP etc) by our gfx department and sometimes CharPad 1.0 or Sprite Pad for Windows (C64 tools)

Sound-FX own routine or using RMT, for music our msx guys use RMT.

4. Recommended game source code written in assembly language to study the game development?

Start with Pac Man or Space Invaders likes...

[starwindz]

Thank you very much for your helps. I'll check them out.

[ricortes]

Sorry if this sounds like I am having a Soap Box Attack, two important things: 1) Take as much advantage of the Atari hardware as possible. 2) Structured programming. There is at least one programmer, Stan Ockers, who is somewhat famous for programming good games in BASIC. There have been several programs who have been discussed where the source code was so convoluted they couldn't be helped, AMIS BBS is one of them. You can develop a good program that is spaghetti code but you limit the ability of people to contribute if they can't understand your code.

 

Tools, hehe. I lost most of mine due to various disk and computer failures. The one that is left is too buggy for human consumption. Among other things it does is import graphic 15 screens and convert them to a font. I like BBK Art for designing graphic 12 character sets because it has X,Y cursor position read out which makes it easier to align pixels on character boundaries.

[dmsc]

Hi!,

 

I am currently studying the assembly language using some books such as 'Atari Roots - A Guide to Atari Assembly Language' to make games in my spare time. I have several questions about this.

 

1. What is your development environment? (OS, Editor, Compiler)

I use Ubuntu (currently 14.10), edit with Vim and GVim, compile using cc65/ca65/ld65. I really like ca65 because the workflow is similar to other embedded programming tools.

 

2. Are there any kind of game engines written in assembly language such as MADS?

(Graphics initialization, sprite, sound, joystick engine and etc...)

Don't know of any "game engine", and due to the limitations of the hardware, I don't know if that would make much sense :-)

 

3. What are the sprite and sound editor which you are currently using?

I use my own ad hoc solutions, nothing fancy.

 

4. Recommended game source code written in assembly language to study the game development?

Mmm... I learned by reading decompiled machine code, so I don't know really :-).

[Mr SQL]

starwindz,

this game engine is for the 2600 but has the things you are looking for

 

There is also full Assembly source code on the thread for the DodgeItPA game linked in my sig that uses the engine.

[ricortes]

hehe, recovered an ATR from a backup of a Sequest removeable drive. This will be of no interest to most people, just some BASIC code and files I did maybe 30 years ago. Story goes something like I had been playing UIII and didn't think the code for the dungeons was done well. I even thought AR The City was a little slow. I thinks to myself 'I could write a program in BASIC that would be faster' so... I know I had moved on to programming in Action! by then so this is just some goofy one sided pissing contest with only one contestant.

 

There are only a couple of notes to Starwindz I need to make. These both use graphics 12 mode. You sacrifice a lot of detail w/o having to lose a ton of memory. SHOWUNI.BAS is just a simple intro type screen with a single redefined character set. I think I fooled around in the newsgroup and did this type of thing as data statements fairly recently *BUT* that was more of a goof. There is the program available ~Graphics to Fonts that does something similar on steroids with multiple FONTs. The downside is the FONTs take up as much room as the graphics 15 mode so if you can sacrifice detail it leaves more room for your program.

 

The DEMO.BAS is really fooling around. Once again, it takes advantage of some features and oddities in the Atari. I used the print screen routines to keep it as weak as possible i.e. like someone who doesn't know how to use assembly language. Anyone in their right mind would just use a block move routine in assembly language. It could have been made faster yet just by modifying the DL to target the different memory areas where the strings are stored => Only takes two bytes. You can also use the DL modification to do course scrolling of 4k worth of screen data. So many techniques, so little time.

 

There may be some routines you will find useful like the binary load, DLI, redefined character sets. You still need to get familiar with VBI music/sound and P/M Graphics.

 

I did a quick check and there is 21k free with DEMO.BAS running. Looking at the REMs<I forgot what some of the comments mean or pertinence> I see I said you could have you could have 30+ screens of data vs. the 8 I did. Not sure if that means 21k free with 30 screens of data but I think so.

 

It should be noted that Steve has really been doing yeoman duty getting rogue like games ported to our 8 bits. I am a huge Rogue fan myself. I mention this because the reason those types of games take so much effort is because they were written in C<actually the original rogue was written in Fortran and run through a translator> and expect huge memory, infinite storage, fast character based I/O, yada yada yada. Price of entry type of thing. *IF* you play to the 8 bits strength, you could come up with something not rogue but it should stand on its own merit. Kind of a PacManRogue.

gr12demos.atr