# New demo uploaded: Pirate Kingdoms

## Recommended Posts

### Pirate Kingdoms

View File

A demonstration of the use of C, sprites, and banks to create a tiled map.

Everything is quite primitive right now.  The scrolling is terrible.

The map is 256 x 256 and stored in banks 10-17 (it's 64k).  My plan is of course to make it larger.

Use the cursor keys to move about the map.

• Submitter
• Submitted
02/16/21
• Category

##### Share on other sites

Cool! I didn't pay attention to your warning and went to the edge, and caused a bad subscript error. Whoops!

##### Share on other sites

The map drawing routine is my target.  If I put it in assembly then ... well it'll be superfast.

```rem dx,dy is the top left corner of the map view
bb=0 :rem this prevents us from POKEing the bank every loop
for r = 0 to \rows-1
y = dy + r
y3 = int(y/32) :rem each RAM bank has 32 rows
ba = 10 + y3   :rem there's our bank number
if bb <> ba then bb=ba :poke \$9f61,ba
yy = 32 * (y/32-y3) :rem y mod 32

for c = 0 to \cols-1
x = dx + c

la = peek(\$a000+yy*256+x) :rem tile value
bk=l1(la) :rem MSB for sprite block
ls=l2(la)  :rem LSB for sprite block
s0=s0(r,c) :rem cached sprite address offset
vpoke \$f, s0+0, %00000000 + ls
vpoke \$f, s0+1, %10000000 + bk
next c
next r
return
```

First, the code is a mess.  It's very busy, and seems to be inefficient for simply updating a map.

The data required to update any one tile is:

1. The correct bank and offset of the data.
2. The MSB value to poke.
3. The LSB value to poke.
4. The sprite's register offset.

##### Share on other sites

19 minutes ago, kelli217 said:

Cool! I didn't pay attention to your warning and went to the edge, and caused a bad subscript error. Whoops!

Off by one I suspect.  Thanks for finding it!

Ah, that's a "bug" with my map, not the code.  The first two bytes used to store the map dimensions, causing your error.  I'll upload a new map.

Edited by rje
##### Share on other sites

Yes, it works much better now. Stops and won't let me go beyond the bounds of the map.

##### Share on other sites

Updated with settlements... sort of.

Buggy settlements.  I'm still working out how I want to do the sprite offsets there.  I figure if I can do half-height offsets, I can get twice the number of unique settlements.

Edited by rje
##### Share on other sites

Pretty cool looking for a basic program!

The long initialization phase, is the program creating tiles on the fly or something?  Instead of loading bitmaps?

##### Share on other sites

• 2 months later...
On 2/17/2021 at 7:52 PM, desertfish said:

The long initialization phase, is the program creating tiles on the fly or something?  Instead of loading bitmaps?

Right, it loads the tiles into banked RAM... and then POKEs them into VERA.

I *think* I can load directly into VERA -- right? -- so I should be doing that!

##### Share on other sites

Here's things I want to do:

Migrate the code to C (because I know C)

Then...

•  Improve the map (because... ugh)
•  "Exit" the ship for land travel.
•  "Board" ships for sea travel.
•  Interactions with settlements.
•  Interactions between settlements.
•  New settlements.

Then I can start thinking about events that bring a little Dwarf Fortress feel to things.

Edited by rje
##### Share on other sites

• 1 month later...

Now that Core War is 1.0.0, I've started thinking about Pirate Kingdoms of the Rhylanor Coast.

In C, of course.

I. A PRETTY MAP

First, I need a pretty map.  The current map is ugly.  So I need rounded coastlines.  OK.

II. AN ECOLOGY

• Settlements.  Depending on the type of land and size of settlement, they may grow, have Food (smaller settlements), Gear (larger settlements), and Ships (on the coastline).
• Settlements interact with local flora, fauna, and other Settlements. Their size and gear rating determine the Settlements' radius of influence.  Thus Cities with excess Gear have the largest influence and can be very powerful.
• Fortresses. A special kind of Settlement geared for defense.
• Gear is an economic multiplier.  It stretches out your Food supply.  It makes you more effective in battle.  Gear builds and maintains Civilizations.  A prolonged loss of Gear production causes Settlements to fail and Civilizations to fall.
• An established City may revolt and break off of a Civilization if there are prolonged problems.

III. PLAYER ACTIONS

• barter with Settlements for manpower, food, gear, ships -- if the settlements don't have a bad opinion of you.
• or attempt to plunder them.
• establish Settlements with an initial investment of manpower, food, gear, and ships.
• be a "Primitive Wandering Bandit team", subsisting on trade and plunder.
• be a "Leif Ericsson" band, arriving in ships to settle in an unknown land.

Edited by rje
##### Share on other sites

My first steps will be careful ones.... I've never done sprite programming using CC65.

##### Share on other sites

• 3 months later...

Updated with some more vision statementy things.

I. A PRETTY MAP

• Rounded coastlines, no overlapping sprites.

II. AN ECOLOGY

• (1602) Terrain squares have their own characteristics, which define what can be grown on them.
• (1602, 7 Cities of Gold) Settlements produce people, supplies, ships, trade goods.  Some are better at self-defense.  They can be owned, and can rebel.
• (7 Cities of Gold) A "soft empire" model, based on relationships between settlements.
• (1602, 7 Cities of Gold) Establish and dismantle settlements.
• (Pirates, 7 Cities of Gold) Barter with or plunder settlements.
• (7 Cities of Gold) Explore.

Edited by rje
##### Share on other sites

• 3 months later...

OK, replaced the BASIC version with the C version.  It's more responsive, but the scrolling is terrible.  Also I don't like the way I did the map.  I have to rethink things and use fewer sprites if possible.

For example, I use sprites to tile the ocean.  I shouldn't have to do that -- surely I can just use characters to represent the ocean.  Like a reverse period, or something.

Then, the land sprites themselves are memory hungry.  Each one is 64 x 64 and 8 bit pixels -- 4K!  Oink!

I think I need to go back to using "coastline" sprites for the edges.  8 x 64 and 64 x 8 sprites.  We'll see.

And even after all that, there does appear to be an obvious redraw going on when the ship moves: the sprites appear to stagger.  In other words, C is not fast enough.

Edited by rje
##### Share on other sites

Mainly, you need to make sure you are doing the scrolling during VBLANK by putting it at the beginning of your VSYNC interrupt routine. That should clean it up a lot.

##### Share on other sites

On 1/26/2022 at 9:36 AM, SlithyMatt said:

Mainly, you need to make sure you are doing the scrolling during VBLANK by putting it at the beginning of your VSYNC interrupt routine. That should clean it up a lot.

You can do that in C?

##### Share on other sites

On 1/26/2022 at 2:08 PM, rje said:

You can do that in C?

I should hope so! You may just need some inline assembly to overwrite the IRQ vector with a function address, but you may be able to do that in pure C.

##### Share on other sites

You could also develop this in the direction of the Flying Spaghetti Monster game - fsmgame.com

##### Share on other sites

I forget exactly every step I did in Flappy Bird, but it does IRQ handling in C.

Basically, I made a #define that makes the IRQ vector in RAM (\$030-something)  so it looks like a variable, and then I did an inline assembly to SEI, then IRQ_VECTOR = &irq_handler;

Something akin to that.

##### Share on other sites

Very nice demo. Curious how you created the dynamic tile algorithm.

##### Share on other sites

• 4 weeks later...
On 1/29/2022 at 4:09 AM, svenvandevelde said:

Very nice demo. Curious how you created the dynamic tile algorithm.

I overlapped the sprites significantly -- 8 pixels on every edge I think.

The result was absolutely horrible refresh.

Today I got rid of the overlap and reverted to plain square sprites instead of ones with contoured shorelines.  It looks uglier but moves MUCH MUCH smoother.

The current view is only a bit more than 5 x 6 "squares".  I also added a regional map view -- typing 'm' draws a 50 x 50 PETSCII map.  That helps get my bearings, so to speak.  I might instead just have a 20 x 20 mini-map on a corner of the normal view.

##### Share on other sites

On 1/26/2022 at 9:36 AM, SlithyMatt said:

Mainly, you need to make sure you are doing the scrolling during VBLANK by putting it at the beginning of your VSYNC interrupt routine. That should clean it up a lot.

It doesn't work.  By that I mean it DOES work, but C is so slow it reduces the game to a crawl.

The function I tried using is called waitvsync(), strangely enough.  Standard with cc65's <cbm.h>.

##### Share on other sites

On 1/28/2022 at 10:10 PM, ZeroByte said:

I forget exactly every step I did in Flappy Bird, but it does IRQ handling in C.

Basically, I made a #define that makes the IRQ vector in RAM (\$030-something)  so it looks like a variable, and then I did an inline assembly to SEI, then IRQ_VECTOR = &irq_handler;

Something akin to that.

THAT might work.  Better than waitvsync() anyhow.

##### Share on other sites

I'm impatient now though, and I want to get on with writing some playable content to the game.

##### Share on other sites

Got any images to show?

## Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.