New demo uploaded: Pirate Kingdoms

[rje]

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
  rje
• Submitted
  02/16/21
• Category
  Demos

 

[kelli217]

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

[rje]

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.
 

[rje]

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 February 16, 2021 by rje

[kelli217]

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

[rje]

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 February 18, 2021 by rje

[desertfish]

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?

[rje]

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!

[rje]

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 May 11, 2021 by rje

[rje]

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

Your Group can:

• 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 July 9, 2021 by rje

[rje]

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

 

[rje]

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 October 20, 2021 by rje

[rje]

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 January 26 by rje

[SlithyMatt]

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.

[rje]

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?

[SlithyMatt]

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. 

[pzembrod]

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

[ZeroByte]

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.

[svenvandevelde]

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

[rje]

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.

[rje]

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>.

[rje]

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.

[rje]

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

 

[Ed Minchau]

Got any images to show?