GP2X Jabber's Log-fire

[BradN]

I am really sorry about the BradN misunderstanding. I am a bad person.
...

hey, don't worry about it. Internet misunderstandings happen to the best of us... it's difficult to sense the tone or emotion of communication when all you have are ASCII and some emoticon hacks

 

[Mr.Jabberwocky]

upside down? ive not ran into that before with sdl. maybe its a bmp thing, but its not something I have ran into. I know sdl differs from OGL because of its co-ordinate system which makes the image upside down topright v bottom left...

i like reading things like this (you can read my design escapades for my gp2x game on http://mega-tokyo.com/blog )

It is a .bmp thing. For some reason (that eludes me) they decided to store the scanlines in reverse order. Wow! your project is definately way more 'adventurous' than mine. Good luck with it. How is the GP2X fund going ?

Well, I set out with good intentions. I have this vague concept that I should somehow break this task down in to mangable chunks. I have seen diagrams which start with a single block that has lines drawn to smaller blocks, which in turn are divided into smaller blocks. Each smaller block describing in more detail the larger block above it. In this way I could break the whole process down and end up with an overall understanding of how it will all come together.

The best I can come up with is a block labelled 'Fire' representing the whole program with two sub-blocks called 'Screen' and 'Other stuff'. I know 'Other stuff' should be broken down into processes, but when I think about it I just get a load of unformed ideas bouncing about in my head that I can't quite grasp.

The problem is the first thing that emerged from my brain was this block called screen and my brain wont come up with anything else until that is sorted. It would be nice to have a clear overall picture but it just ain't going to happen.

Basically 'Screen' is a collection of information describing the LCD. It just seemed to flash into my mind and will form the reference for all the other functionality of the program. So it does not seem too bad a thing to get it in place first.

The real LCD seems to consist of humorously shaped 'pools' of liquid crystal that can be switched on and off. The idea for representing it may need refining but will look something like this :

Screen
	background
		pool_1
			x position
			y position
			humorously shaped graphic
		pool_2
			x position
			y position
			humorously shaped graphic
		pool_3
			.....etc.
	foreground
		pool_1
			x position
			y position
			humorously shaped graphic
		pool_2
			x position
			y position
			humorously shaped graphic
		pool_3
			.....etc.

This will organise the images into background - ambulance, building, etc and forground - firemen, jumpers etc. It will also hold their positions on the screen and the image for that position.

Funny thing. After typing this out those bouncy unformed ideas have become a little clearer. But not by a lot.

 

[Mr.Jabberwocky]

Being the weekend and everything I have, naturally, done sod all. But now I am trying to recall exactly what I was thinking last time I did anything. It seems the last thing I did was throw all the graphics into this .bmp :

xnopasaranx suggested that there should be an option for a colour version. I like the graphic forms but agree it would be great to have coloured versions of them.

However I am too lazy and not talented enough to do the job justice so would like to know if anyone would enjoy colouring in the existing graphics. In exchange you may feel a sense of satisfaction and your name will be linked to what, possibly, will be the worst home brew game ever released for the GP2X. You will get full credit in the program (unless you would rather not have your name associated with this production, in which case I guarantee total anonymity).

There are a couple of restrictions : It is an 8 bit(256 colour) image and the images must keep their size and position in the bitmap. The choice of pallette is up to you.

In the colour version there is the possibility of adding enhancing background images. Possibly a pavement, street furniture - fire hydrants, pillar boxes etc. Maybe some background image like a city skyline ? So, although this is presented as little more than a colouring job there is scope for you to add your individual artistic mark.

If you do want to do it, just download the image and leave a reply to let me know. Thank you.

BenScar ? WarmFluffyUK ? Anyone ?

 

[Mr.Jabberwocky]

I have implemented a list that represents the display. Each item in the list represents an object on the screen and consists of three elements :

• an on/off indicator - used to indicate if the object is to be displayed
• the position of the required graphic data in the bmp file
• the position it appears on screen during the game

It is then just a matter of reading through the list and blitting the data from its position in the bmp file on to the screen if the 'on' indicator for the graphic is set.

The next step must be to have something to read the input and use it in a meaningful way to set the appropriate firemen graphic to its 'on' state. I think the shoulder buttons would be the best method of control but left/right on the joypad will also do it.

There also needs to be a way to control up to 9 (according to the manual) jumpers. This will have a mass of things to do that I now have to try and formulate. As I type, this is the first time I have tried to list what is needed for a jumper:

• He has to appear at his starting position - this will be determined by things like how many jumpers are currently jumping and how long the player has been playing. So it has to start off slow with one jumper at a time and progressively increase speed and the number of jumpers. I need to study the manual but I think after a certain score is achieved the whole process starts over i.e. going back to just one jumper and building up to nine again.
  
• A jumper has to progress along a sequence of positions on his journey to the ambulance. This is complicated by the fact that there are two start positions thus two paths. The second path only comes into play in game B.
  
• A jumper has to break his journey and fall on his arse if the player is not in the right position at the right time.
  
• Presumably a jumper can not start if it would result in there being two jumpers who need 'bouncing' at the same time ? Or is there enough time to move the firemen to deal with both ? I am starting to get a sharp pain behind my right eye trying to think about it.

Hopefully at some point today I will have the time and the correct levels of caffeine and nicotine in my system to deal with this but right now I need an aspirin.

 

[torpor]

my advice having read this thread: use CAIRO+SDL ..

 

[Mr.Jabberwocky]

Thank you for your recommendation. I am using SDL. I have looked up CAIRO and it says it is a vector graphics library. So I am not sure if it would be of any use to me for this particular 'project'.

One of the hopes I had for this thread was that as I presented my feeble attempts at putting a game together the more experienced members would point out how it really should be done. In this way a guide for the new coder full of the wisdom of the board members will be created.

Any recommendation that is geared to the noob and avoids scary references to second processors, asm, caches and Magic Eye documentation is highly valued. So your suggestion of an additional library is very welcome.

Could you expand on why you think CAIRO would be of benefit ? Even if I can not use it for this simple exercise, it may be just what others are looking for.

Here is a link to CAIRO.

Here is a link to the SDL reference I am stealing most of my code from .

 

[YakumoFuji]

I know with donkey kong i (orange) and DK3? (brown) the games would consistently speed up until you hit 300 points (300 was extra life) then reset themselves back to low speed.

I'm pretty sure green house was the same. (dang! i just sold my G&W gallery carts for the gbc/gba or I would check).

 

[BenScar]

not talented enough to do the job justice
BenScar ?

I think you summed up my graphics capablities just there (plus I'm colour blind!)
More hands on programmer than graphics artist... I'll pass the thread on to someone I know who DOES have a good design mind though (You listening Mark?? )

 

[Mr.Jabberwocky]

@YakumoFuji : Thanks for the info
@BenScar : Cheers ! If he will help, the graphics might be the one saving grace of this whole thing.

Yesterday I fell victim to the excesses of the weekend, and by the evening I could not face running up codeblocks and suffering the abuse the compiler hurls at me every time I ask it to check out my code. Instead I checked out WarmFluffy's Myriad and felt inadequate when comparing her stunning results to what I am attempting.

However, about lunchtime I had had a moment of clarity and came up with the following structure for controlling my virtual lcd. I am bound to have overlooked things (already Yakumofuji has mentioned an extra life that I did not consider) but I feel it is enough to get started with. Any ommissions will show up as I go along and will have to be shoe-horned in then.( I have a vague intuition that this approach is probably up there in the ten commandments of how not to code).

game control stuff - 1 of these
	score
	lives
	current number of jumpers
	required number of jumpers
	JumpA				- signals to prevent a jump starting if it will result in two jumpers 
	JumpB				- needing 'bouncing' at the same time - have not really thought it through yet
	other stuff probably

object control stuff - 1 firemen, 9 jumpers, 1 faller, 2 flash - maybe more
	is it active ?
	type					- fireman, jumper, faller, impact flash( when faller hits the floor)
	current lcd image
	process status for jumpers	- waiting to jump, bouncing, hit the deck, dying, reached ambulance etc
	my brain hurts
	

initialise game
	clear score
	set number of lives
	turn off all lcd images
	set current number of jumpers to 0
	set required number of jumpers to 1
	set starting position of firemen
	turn on firemen lcd image


control firemen
	read input
	use input to determine required lcd image
	turn of current lcd image / turn on required lcd image


do we need a new jumper ?
	is number of jumpers < needed jumpers
	yes - start a jumper
		if < 9 jumpers
			is there is a jumper waiting to jump
			yes -	forget it

			no  -	get the next available jumper
				make active
				set process to begin
				add to current number of jumpers
	no - based on the score, calculate the required number of jumpers


process jumpers
	if time to process
		for each jumper
			if process is begin
				can we jump - determining differs if its an A jumper or B jumper
				yes -   set next process - bouncing
					disable current lcd item and select next
					set step to 1
				no  -   signal jump to yes
			if process is bouncing
				disable current lcd item and select next
				if step = catch 1, catch 2 or catch3
					if firemen not in position
						process = dropped
					else
						score a point
				if step = last
					process = success
				add to step count
				if step = jump 1, jump 2 or jump 3 - prevent jumps that result in simultaneous 'catches'
					signal jumpA to no
				if step = jump 4, jump 5 or jump 6
					signal jumpB to no
			if process is dropped
				disable current lcd item and select dropped lcd items for this catch position
				set process to dead
			if process is dead
				decrease jumper count
				enable the next angel and decrease number of lives
				if number of lives is 0 signal end of game
				turn off this jumper
			if process is success
				decrease jumper count
				turn off this jumper

Tonight I hope to get this running !

 

[marmakoide]

Finite state machines could enougth to control such LCD games, don't you think so ? You will a have a generic emulator of LCD games. An LCD game is a finite state machine with a picture file. My 2 cents.

 

[TheMinder]

I know you are fairly on with the graphics, but i found these while looking for something unrelated and thought i'd pass the link on : http://tsgk.captainn.net/index.php?p=searc...=game+and+watch

 

[Mr.Jabberwocky]

Finite state machines could enougth to control such LCD games, don't you think so ? You will a have a generic emulator of LCD games. An LCD game is a finite state machine with a picture file. My 2 cents.

Hi. Having a universal Game & Watch program would be so cool. It could even have an editor for people to build their own games with. The user could load up a bitmap showing all the elements in their proper positions and the editor would allow them to define the order of play.

I think this would require a somewhat superior ability to mine. I have found it difficult enough setting things up to do a known sequence of things. If I had to try and make it flexible enough to accept any possible sequence I would be out of my depth.

But you have now got me wondering about it - maybe a future development (if I ever get this one finished).

I know you are fairly on with the graphics, but i found these while looking for something unrelated and thought i'd pass the link on : http://tsgk.captainn.net/index.php?p=searc...=game+and+watch

Thanks for the link. It never even occurred to me that ther might be some ready-to-go sprites out there in Web Land. I see those images do include a seven-segment digital sequence that could be handy for displaying the score.

Tonight I hope to get this running !

Well there is hoping, and there is reality.

To implement the plan I came up with, I first had to fudge together the required storage for the objects. I then realised I would need to have an initial function to set them all up. Then my Mum rang up and talked for 40 minutes about - nothing at all really. But it was nice to hear from her.

I then realised I knew not how to read the joystick in a useful manner - had to spend time searching these forums for info. Of course I found it here - thank you forum members.

As it now stands I have only managed to get as far as controlling the firemen. But it is running in a loop and flipping the screen and the player can move left and right.

​

 

[YakumoFuji]

not sure if you have it but here is scoring info;
http://www.intheattic.co.uk/fire.htm

the second one below this has different scoring.

Takes a long time to score as you only get a point for each man you get into the Ambulance (FR-27 gives you a point for each time you bounce a man on the trampoline).

Highest possible score is 999.

Cheats and tricks:
Every 100 points the evacuees reduce in number, before increasing again. Use this relief to take a little breather.

Points:
1 point for every evacuee you manage to get into the waiting ambulance. The lamp on the ambulance lights up.

Misses:
When the player fails in receiving an evacuee a miss is recorded. With 3 misses (shown by angles on the upper right side of the screen.), the game ends.

here is the other edition of fire;
http://www.intheattic.co.uk/fire1.htm

In game A the people jump only from the fourth floor, whereas in game B they also jump from the third floor, so it's a bit more difficult.

Maximum score is 999 and when the score reaches 200 & 500 points all misses are cancelled.

Cheats and tricks:
Speed increases with score. With each 100 points, speed returns to normal so you can take a breather before it start to get faster again.
As score increases the evacuees come down in greater numbers. A maximum of 9 evacuees can be on the screen at any one time.

Points:
1 point for every time you receive an evacuee.

Misses:
You get one miss, if you fail to receive an evacuee and he falls on the ground. Three misses (shown as angel marks on the screen) and the game ends.

 

[torpor]

Hi. Having a universal Game & Watch program would be so cool. It could even have an editor for people to build their own games with. The user could load up a bitmap showing all the elements in their proper positions and the editor would allow them to define the order of play.

One word for you: SVG.

Make a G&W engine that takes as input a standardized SVG file where the elements are named standardly, and away you go .. no need for bitmaps, no need for an editor, since Inkscape runs just fine on all relevant platforms ..

 

[Daid]

Hi. Having a universal Game & Watch program would be so cool. It could even have an editor for people to build their own games with. The user could load up a bitmap showing all the elements in their proper positions and the editor would allow them to define the order of play.

One word for you: SVG.

Make a G&W engine that takes as input a standardized SVG file where the elements are named standardly, and away you go .. no need for bitmaps, no need for an editor, since Inkscape runs just fine on all relevant platforms ..

[sarcasm]Ah, yes, yes, I see how the standard for a graphics system helps you defining gameplay without an editor.[/sarcasm]

 

[Mr.Jabberwocky]

not sure if you have it but here is scoring info;
http://www.intheattic.co.uk/fire.htm

Thank you for your assistance. After reading your post a lot of 'research' was undertaken using the previously mentioned 'emulator'. I can not actually reach 200 points but my flatmate can clock the thing. It plays the version where you get a point every time you 'bounce' a jumper, and he has confirmed the scoring system you report. The 'emulator' uses the the second system.

Progress is slow. I now have the jumpers working, they jump, they bounce, they fall, they get saved, they increase in number and get faster. I count the bounces. An angel appears for each miss and the game stops after three misses. I was feeling pretty chuffed with myself......Until my flatmate tells me that it just all wrong. I have the jumpers jumping and progressing a step on every 'tick' of the game.

He showed me that it just does not work like that. Using a metronome (he is a musician) he established the game to start at about 98bpm - that is to say a jumper moves position on this beat. However each time the player 'bounces' the jumper, the jumper shifts phase by a third of a beat so that a new jumper will not move at the same time the 'bounced' jumper does. The second 'bounce' shifts the phase again so that there can be three movements happening in each beat - a jumper dropping from the window, a jumper who has been bounced once and a jumper who has been bounced twice. The third time the player 'bounces' the jumper (into the ambulance) the phase is back in time with the initial jump.

This really does give the game a lot of its character. It also circumvents the possibility of the player having to bounce two jumpers at the same time (I think ?). It also hurts my head trying to think about how to implement it.

Back to the drawing board I guess.

 

[torpor]

[sarcasm]Ah, yes, yes, I see how the standard for a graphics system helps you defining gameplay without an editor.[/sarcasm]

Works for me. I have an engine that reads in an SVG file, looks for the nodes named in the engine-dictionary, uses those nodes as 'planes' (as in surface, not aero-) in the game machine, flips planes on and off according to the needs (just like the custom LCD masks in the G&W machines) of game-play, and away we go.

Do I want to come up with another game? Yes: Make another SVG file, different graphics, but nodes named the same according to the engine-dictionary, and oila: another, very easily built, level for the engine ..

(I see your sarcasm as ignorance, so I won't take offense..)

SVG: Structured Versatile Graphics. Use it as the skin-container, create a well-defined engine-dict, and off you go ..

 

[Mr.Jabberwocky]

One word for you: SVG.

Make a G&W engine that takes as input a standardized SVG file where the elements are named standardly, and away you go .. no need for bitmaps, no need for an editor, since Inkscape runs just fine on all relevant platforms ..

I kind of zoned out when I saw yet another acronym I was unfamiliar with. But this SVG sounds interesting. I cannot understand how you do not need a bitmap or an editor. I would have thought you use some kind of editor to create the SVG and it will need to refer to a bitmap, surely ?

I will continue with my inflexible, one-game approach for this project but I will certainly look into SVG if I still have any enthusiasm left when I have finished this. Having to come to grips with SVG as well as SDL (Oh God! Nooo! Now I am starting to talk in acronyms) would be overload for me. Thank you for the suggestion.

 

[Daid]

(I see your sarcasm as ignorance, so I won't take offense..)

SVG: Structured Versatile Graphics. Use it as the skin-container, create a well-defined engine-dict, and off you go ..

I rather see it as, total lack of info from your side. You throw a term here "SVG", turns up as "Scalable Vector Graphics" on google. Other then that I don't have time to read 300 pages of documentation on it. Now you describe it as "Structured Versatile Graphics", and thus making the confusion compleet. EXCUSE me for not knowing all 1239078503284032 diffrent terms that are invented every day.


Now, back to Jabber. Any idea when you have something the public can play?

 

[Mr.Jabberwocky]

Now, back to Jabber. Any idea when you have something the public can play?

I have reimplemented the jumpers to use the 3-phase movement and it now feels much more like the real thing (well more like the emulator I am using).

At the moment it only plays 'GAME A' (i.e. all jumpers start at the third floor).

I find it really difficult to play the emulator and analyze it at the same time so I have not quite got the speeding up sussed or what the conditions are when the number of jumpers increases. I have some arbtrary settings that I will try and adjust as/and when the way the game performs sinks into my dense head.

I even don't really know how it decides when to start a new jumper. There definately seems to be some random element.

I also need to add in the 100 point relief (reduction in jumpers) and the 200/500 point 'clear all misses.

It needs to play by itself when the user is not playing.

Like Pac man, Game & Watch would be a shadow of its self without the crappy sound, so that has to be put in.

The graphics are extremely poor. The jumpers seem to gain or lose several stone every time they move. Also there have been no takers for my generous offer to allow someone to make some colour graphics.

It is hard to believe how such a simple game could involve so much bl**dy work.

Tomorrow I really have to catch up with all the real life events that I have been putting off so I will not be able to put much time into it - then it's the weekend. If last weekend is anything to go by I still won't have recovered enough on Monday to do anything - so it does not look like I will have anything for about a week. (providing Tuesday and Wednesday stay clear).