Home » Page 3

Drag and drop menu with JQuery UI

It’s quite simple, but since how-to questions are popular here’s little tutorial. Read more

Waiting for a loop in node.js

Another short battlefield report.

I know it’s quite against node.js way of coding, but I really needed to implement two synchronous loops, where one waits for another. Read more

Using jsdom module with jQuery site.

Jsdom is helpful implementation of DOM for node.js. It’s great to do some server-side html generation with jQuery, but there’s a little problem when working with site that already use jQuery.

Consider a scenario:
-> UML creating tool with html5 & jQuery UI, with account system.
-> We want an onload list of projects owned by or shared with user.
-> List is stored on db.
Read more

Cookies via http requests and headers.

Okay, my silence becomes annoying. I know that thesis is important but…

Well… I plan to detail it later, when it’s finally complete so todays note is just a teaser, and some kind of news from battleground. Read more

Asokoban screenshoots!

Well, maybe it’s a bit late to post them – after all it’s been a whole month since uploading Asokoban on github, but hey. Better late than never, as they say in my country (:

Duu duuun! Read more

MapView

The most challenging part of Asokoban was creating a map to play on.

Now I wonder if it wasn’t an overkill but with experience from WinForms I decided to implement map with a Canvas on a custom View called MapView, because sokoban is a game that does not require much frame-rate speed – map should be redrawed after each move, and time gap between moves varies according to time player spend on thinking. Read more

Common menu in android apps

Little trick, that goes well with DRY rule.
Every activity on android can contain menu defined in onCreateOptionsMenu(Menu menu) and onOptionsItemSelected(MenuItem item) methods. But what to do if we have multiple activities that share the same menu? Copy and paste methods? Better not. API Guides at android developers come with a trick: when multiple activities need to provide the same, common, menu a best way to do it is through inheritance.

In Asokoban I wanted a common menu with “about” and “highscores” options, that would show basic info about program, and highscores activity. And in-game activity menu should also contain a restart option. How?
I created a MenuActivity as a “empty” activity that implemented only methods connected with menu. Standard and one that implements tasks specific for options item. Example:

public class MenuActivity extends Activity {

	@Override
	public boolean onCreateOptionsMenu(Menu menu) {
		getMenuInflater().inflate(R.menu.menu, menu);
		return true;
	}
	
	@Override
	public boolean onOptionsItemSelected(MenuItem item) {
		switch (item.getItemId()) {
		case R.id.menu_about:
			showAbout();
			return true;
		case R.id.menu_highscores:
			showScores();
			return true;
		}
		return super.onOptionsItemSelected(item);
	}
	
	private void showAbout(){
		AlertDialog.Builder builder = new AlertDialog.Builder(this);
		builder.setMessage(R.string.about_content)
	       	   .setTitle(R.string.menu_about);
		AlertDialog dialog = builder.create();
		dialog.show();
	}
	
	private void showScores(){
		Intent intent = new Intent(this, HighscoreActivity.class);
		
		startActivity(intent);
	}
}

Then all that’s left is to extend this class for every activity in program. And – in case of ingame activity with reset function – override onCreate and OnSelected methods with additional menu content. Example:

	@Override
public boolean onCreateOptionsMenu(Menu menu) {
super.onCreateOptionsMenu(menu);
menu.add(Menu.NONE,ID_MENU_RESTART,120,R.string.menu_restart);
return true;
}

That warehouse.

We Interrupt notes about pongoid to proudly present: Asokoban. A simple sokoban clone made for my ‘mobile programming’ at university.
It was first app I ever made for phones with android so code is little messy and it’s clearly far from optimal, but I’m still learning.

For now game contains 2 levels, and simple highscore system made with shared preferences.

I plan to write more about implementation in the next few notes.

One thing at one time.

I decided to do more often, but shorter sessions. It suits these short free time gaps I have lately.
These last sessions were another Refactoring ones with aim of extracting functions, so one could do only one thing, instead of all purpose procedures like DeleteSpritesAndFonts(), or two purpose DrawScene().

Soo little changes list:

-> Cutted PrepareSpritesAndFonts() and DeleteSpritesAndFonts() to four functions:
PrepareSprites, PrepareFonts, DeleteSprites, DeleteFonts.
Now all that’s inside PrepareSpritesAndFonts is:

bool Game::PrepareSpritesAndFonts()
{

	if( PrepareSprites())
	{
		bool ret = PrepareFonts();
		return ret;
	}
	else
		return false;
} 

I think it looks better this way. Now it’s easy to tell what’s really inside, and extracting DeleteSprites() helped to delete redundant cleaning after failing with preparing fonts.

-> Also I properly named arguments in headers, so that intelisense can help what’s the meaning of what variable passed to methods (yeah, the fact I haven’t done it at the begining sucks).

-> Bid farewell to victory, running and pause variables, and welcome our new datatype GameState enum! Now with all new Defeat state.
Although it was a little confusing to replace them at first, because of

while(running)
{
   // Loop with redrawing and listening to keyboard events
} 

loop, that created a little confusion. If I’d replace ‘running’ with a condition like (gameState != Victory && gameState != Defeat) it’d be confusing. Why game should run in paused state, but should not in Victory, nor Defeat?
After putting some thoughts I decided to make while a simple infinite loop with breaks after goint into Victory or Defeat. I bet it’s still far from perfection but I like it. For now.

-> Extracted “DrawPause()” from DrawScene – it was unnecessary to check all the time whether game is running and then if it’s paused.

-> Probably it’s a bit obvious, but al_flip_display() can be called only once. It’s unnecessary to do something like that:

	if (gameState == GameState::Running)
		DrawScene();
	else if (gameState == GameState::Pause) 
		DrawPause();
	else 
		DrawEnd();

with ending all procedures with al_flip_display. It’s enough to call it at the end of Draw calling function.

-> Slight renaming. Variable Hp is now known as Lives, and pong is now a pongSprite.

As always you can find changes in repository.

Finally…

Someone might think that three day week is a thing easily done, but sometimes everything just happens at the same time. One university project after another and carring out duties. I’m really glad it’s over for now, but I fear that I won’t have time in may to perform a long coding sessions.

For now I simply standarized language used in naming classes and variables. Until today it was (as you could see) little messed up with english names (classes, most of function names and variables), with polish (mainly translation of english names).

And so changes for today’s short session:
-> A Game class object name changed from gra (polish for ‘game’) to App.
-> List of brick objects name changed from kafelki (polish for ’tiles’) to Bricks.

Also I reviewed most of code, and got a basic idea what should I change to improve quality of the code.

Hope to code it soon (:
Also those (rather slightly) changes are in repository.