Archive for May, 2012

29
May
12

Pong Clone in Pascal

One of the every first graphical programs I wrote in pascal was a very basic pong clone. All the graphics were done using the Borland graphics library using vector style graphics. So you will need the bgi and chr files to build and run this program. Again I had to adjust the timing for this program as the original timing system would have only worked on the old 386 I developed this on! You’ll notice that the program made use of the goto statement in pascal which is generally frowned upon. This is because it is one of my earlier pascal programs, and I still had many bad habits from writing many programs in BASIC.

Continue reading ‘Pong Clone in Pascal’

Advertisements
24
May
12

Num Drop Pascal source code

This is a pascal version of one of the very first gwbasic games I ever made. I’ve made improvements over the original but it is still pretty true to what it was. It should be pretty simple to compile as it only requires the dos and crt units to function. Source code follows…

Continue reading ‘Num Drop Pascal source code’

23
May
12

Some Interesting articles…

In doing some reading around the internet about processors I recently read an article which explains the design of modern microprocessors in a very nice and easy to understand way. You can find it here. Also of interest from the same author is a short piece about exception handling that you can find here. I tend to agree with him that exceptions are a bit of a problem in programming languages, and also avoid using them much like he does. I find exceptions generally only useful to me when trying to debug code that is throwing an exception. What I typically do is try to catch it at some point and print out the stack trace and useful variables, sometimes including actions and information from other relevant portions of code. I only do this with java as you are kind of stuck with the API throwing exceptions in some cases, otherwise I try not to use them at all.

21
May
12

Turbo Pascal for DOS

Turbo Pascal 6 about Screen

Turbo Pascal 6 about Screen

When I was a teenager I mostly wrote programs using gwbasic or qbasic. Around the time when I was about 15 or 16, my computer studies teacher gave me a copy of Borland turbo pascal 6 to try out and learn. It was a much different language to BASIC, and I unfortunately didn’t have any books to help me learn about it. Fortunately my teacher gave me a couple of sample programs so I could learn the structure and basic syntax of the language. I also compiled and inspected the code samples that came with it, and found them informative. However with out more good examples and information about hardware there were many tasks that were difficult.

One of  the main differences in pascal is the way that variables and functions are declared. Unlike C and other languages, variables can not be declared in the middle of a piece of code. There is a separate declaration portion to define them and their data types before they are used any where. This is good in some ways as it forces you to think about what you are going to need for your program, function or unit.

One of the very new things that I learned about that is very common, but not available in BASIC, was pointers. For the uninitiated a pointer is basically a number that “points” to a memory location in the computer. They are useful for dynamically allocating memory or dealing with large chunks of data. They are necessary in pascal to avoid filling up your data segment. Unfortunately they are also one of the easier things to get wrong. I avoided them when I first started writing in pascal as I had no knowledge about how they were used. Also I had very little need as my programs typically did not fill the data segment, but as the programs grew and I started using bit-mapped graphics, they became necessary.

A Open Program

An Open Program

Graphics and sound were also a very big change for me. Graphics was through a unit (library) called graph which utilised something called BGI (the borland graphics interface). Unfortunately I couldn’t get it to support the graphics modes that I was after at the time (320x200x256), as there was no BGI driver available for it in the language. Bit-mapped graphics also required that I used what was unfamiliar; pointers. So for quite a while graphics were right out of the question until I over came these hurdles later.

Later when I went to university I started to solve these problems, I found BGI drivers that supported VGA and VESA graphics modes, and learned the proper use of pointers for storing data as well as doing graphics. I later started writing in-line assembler into my programs to create my own hardware interface routines, the one I use the most being one I wrote for the adlib sound card.

Bob’s Fury

Bob's Fury Title Screen

Bob’s Fury Title Screen

Bob’s fury was one of the first projects I started back in 1999, it is a port of the original game that I wrote in QBasic. Arriving at university I had my first access to the internet and found solutions that had previously stopped me porting this to pascal. I found myself some BGI drivers that allowed the graphics mode I was after but also a higher resolution mode. I also found a nice pascal library that implemented the BASIC play statement. This made porting the sound from the original much easier.

Bob's Fury gameplay

Bob’s Fury Gameplay

I have continued to work on this game to this day, and it has changed a lot since the early days. I’ve added many features to the engine that weren’t possible in QBasic, and created more content for it. More recently I have been adding some of my own hardware interfaces, such as one for the keyboard and one for adlib sound cards, although I am yet to make some decent music for it, or the utility to create it. I’ve actually completed most of the game, but need to now create some new original levels for it as well as some story.

Romulus

Romulus in action

Romulus in action

My brothers and myself occasionally play a game called VGA planets. One of the enduring problems for us was that it would take too long with us playing so many of the human players, and there have not been any reasonably good AI players who also play as the shareware player. I know it’s sorta strange we liked playing the restricted version, but for us it introduced strategy elements that are not present in the registered version. So to help solve the problem I started to implement my own AI that would be better than many of the basic AI utilities out there.

I implemented it to behave the same way a player would as best as possible. The player reads result files and outputs turn files instead of modifying the host files directly like many other AI programs do. In this way Romulus cannot cheat, much the same way that spacelord doesn’t cheat. My focus has been to make the player reasonable good at taking advantage of the various abilities, and to be able to respond to various messages and threats such as ion storms. I’ve even attempted to implement a basic system of diplomacy which allows the player to select who it wants to wage war on.

It still needs quite a bit of work on it before I consider it complete. There are also a few segments I need to redesign and implement as the player doesn’t always do what I’d like it to. The main thing I need to do is to add more of the special abilities to the player.

Pascal Resources

There are many pascal resources around the web, but one of the best resources you can find for writing pascal on DOS is called the SWAG. Basically it is a collection of documentation, forum/BBS questions and answers, and code snippets sorted into different categories covering all the major aspects of programming in pascal. Information about programming the x86 hardware is some of the best and most useful content, especially if you are programming for DOS. I would highly recommend getting it if you can.

Pascal isn’t dead

There is a nice open source project called free pascal that implements a full pascal language including object-oriented extensions. Fortunately it is mostly syntax compatible with your old Borland pascal version 6 and 7. So you can use it to port old programs. I have noted it will also generate code for multiple platforms, including most of the operating systems and architectures that I am interested in. There is also a Delphi equivalent called Lazarus that will help you create new applications! The free pascal website is very useful, and has documentation to help you port your old programs and for the API.

13
May
12

Profiling an Android Application

As you may or may not know, I have been writing an app for the Android platform using OpenGL. Anyone writing for OpenGL on the Android platform should know that it is important to make sure your code is memory efficient, and most importantly fast. In order to achieve this it is important that you test and analyse your code on a regular basis. There are some useful tools that come with the Android SDK and some that can be downloaded with eclipse that you should use.

For profiling you application you should use Traceview. In order to make effective use of this tool you need to make a trace file covering the time frame that you are interested in. You can do this with eclipse, but the length of the trace is limited, and it can be inaccurate. I suggest that you make use of the android.os.Debug class to make the trace file, because you can control the size of the trace buffer.  I have used Traceview to analyse the lengths of time it takes to execute elements of my rendering code, and to monitor the changes in timings when I have changed my code.

For analysing how much memory you are using there are several things you should do. Firstly take a look at the output of logcat and see how often the garbage collector runs and how much memory it frees each time it does. If your app creates and releases objects on a regular basis, the garbage collector will spend a lot of time cleaning up memory which will slow your app down. The garbage collector will also tell you how much heap memory you are using. You need to be aware that there is limited heap space available to apps on Android phones. Some have a limit of 24Mb of heap, but it differs from device to device. So you need to be careful of the amount of RAM used by your app, even if the target device has a lot of RAM. A good way to find out how your app uses memory is to use the eclipse memory analysis tool. It is fairly simple to get working in eclipse, and like method tracing can also be activated by the Debug class. I found that I had to limit the results of all my searches to my project classes to get useful results. There are a number of other classes that belong to the Android API that take up a significant memory space in a small app. Either way the analysis tool is very good, but can be a little complex to use if you don’t know the terminology.

The tools have been useful to me in finding some areas of my code which could be improved, and quantified the improvement. I found a section where I had created a String object implicitly in a method call. When the method finished the String was no longer needed and the garbage collector would kick in once every two seconds. I changed my code to use a different data type and not create objects implicitly and got the relevant code to run twice as fast in addition to not requiring the garbage collector as often. I have also been able to determine the amount of memory my objects require and tune them appropriately.

The analysis tools are only half the solution. Your application needs to have a good solid design, to make it easier to diagnose and correct problems. Lastly it is important to know how to interpret the information from the tools. Many parts of the analysis tools cause slow down or extra memory use, so you need to be aware that the statistics presented are relative to each other and don’t always represent the result on real hardware. If used effectively profiling and memory analysis will allow you to significantly improve the performance of your applications.

06
May
12

Squarez for DOS

Squarez was made and released by Adam Pederson originally back in 1992. It is a puzzle game much like Tetris and other block games, but different in that the blocks do not fall from the top of the screen. The field of game play is divided into two sections by a bar, which can be moved backwards and forwards to change the amount of space available. Two players can play against each other using the bar to restrict the playing space of the other player. Like Tetris you get a number of blocks in puzzle like shapes, the difference is that to make the tiles disappear you need to shape them into squares of a minimum size of 3×3.  Depending on the difficulty level you can get tiles that perform special actions when activated by placing them in squares. Each player has a entryway that you must keep clear, for if you get a piece stuck in it your game is over.

The graphics are very good and quite pleasing to the eye. The quality of the sound is also very good whether it is from the PC speaker, or from a Sound Blaster or Adlib sound card. You can control the game using either the keyboard or mouse, and it may be possible to use a joystick although I never have tried to connect one. Controlling the game itself is responsive, and accurate. The blocks go where you want them to and you are able to do it quickly, which is definitely a good thing as this allows you to score quickly, and hopefully also move the bar quickly to squash your opponents space. The mouse is definitely the best control device to use as it is the fastest way to place blocks. The keyboard is more precise, but not as fast, so it is possible to beat an opponent with the keyboard, but it takes significant skill and a bit of luck.

We originally got this game on our 386 on a shareware magazine cover disk. We played the game competitively between ourselves quite a bit, and occasionally still play it this way today. There are a couple of bugs that you should be aware of, the shareware version would crash if you push the bar too far to either the left or right. The latest registered version seems to stop both players controls if one player loses leaving the other immobilised. These problems however don’t detract from the game being very fun and addicting.




Blogs I Follow

Enter your email address to follow this blog and receive notifications of new posts by email.


Mister G Kids

A daily comic about real stuff little kids say in school. By Matt Gajdoš

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm's Vintage Computing, Tech & Scale RC Blog

Random mutterings on retro computing, old technology, some new, plus radio controlled scale modelling.

ancientelectronics

retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way

lazygamereviews

MS-DOS game reviews, retro ramblings and more...