Jump to content
IGNORED

Bently bear level editor??


Ecernosoft

Recommended Posts

Hello!

@PacManPlus, before you tell me I ask too much, I know.

I noticed it said something about a level editor in the text above the screen (It also says Copyright Atari 1983, Program by Bob, Music by Synthpopala, etc).

I was wondering if you still had the level editor and if it runs on PC or on the Atari 7800, and if it is the latter if it requires special hardware. I'd also love to know how you dealt with level compression and that stuff.

 

Just asking, Thanks! If there's an efficient way to encode levels for use in atari 7800 games I'll take it!

Link to comment
Share on other sites

1 hour ago, ZippyRedPlumber said:

It's in the Crystal Quest Forum, @jwierer made it.

 

Here's the link: 

 

Hey, I'm having problems...

I can't do anything! I can't make new graphics, lay down tiles, or miuch of anything! I can select colors and go to the settings and the different options but that's it. What am I doing wrong?

Link to comment
Share on other sites

10 hours ago, Ecernosoft said:

@PacManPlus, before you tell me I ask too much, I know.

I noticed it said something about a level editor in the text above the screen (It also says Copyright Atari 1983, Program by Bob, Music by Synthpopala, etc).

I was wondering if you still had the level editor and if it runs on PC or on the Atari 7800, and if it is the latter if it requires special hardware. I'd also love to know how you dealt with level compression and that stuff.

Of course you are going to ask questions if you are trying to lean. :)

 

7 hours ago, Ecernosoft said:

I can't do anything! I can't make new graphics, lay down tiles, or much of anything! I can select colors and go to the settings and the different options but that's it. What am I doing wrong?

I forget off the top of my head, as it's been quite a few years since I've used it.  But if I remember correctly you need to click on a wall piece and then on the representation of the level itself to place a tile.

 

Link to comment
Share on other sites

42 minutes ago, PacManPlus said:

Of course you are going to ask questions if you are trying to lean. :)

 

I forget off the top of my head, as it's been quite a few years since I've used it.  But if I remember correctly you need to click on a wall piece and then on the representation of the level itself to place a tile.

 

Lean? Lean? lol. 

 

It's not just placing a tile, I can't edit a tile either. I use windows 11 so is that why it isn't working?

Link to comment
Share on other sites

 

 

 

39 minutes ago, Ecernosoft said:

Lean?

That darn 'R' key keeps moving :ponder: :) 

 

 

I'm actually not sure; like I said it's been a while since I've used it.  I guess it's possible that it could be Windows-related, although I think you would be getting errors about DLLs missing if that were the case.

 

 

Link to comment
Share on other sites

8 hours ago, PacManPlus said:

 

 

 

That darn 'R' key keeps moving :ponder: :) 

 

 

I'm actually not sure; like I said it's been a while since I've used it.  I guess it's possible that it could be Windows-related, although I think you would be getting errors about DLLs missing if that were the case.

 

 

You know, the main reason I was so interested was the compression method, but seeing as how there is no compression in bently bear, I might just go back to my old methods.

Link to comment
Share on other sites

9 minutes ago, Ecernosoft said:

You know, the main reason I was so interested was the compression method, but seeing as how there is no compression in bently bear, I might just go back to my old methods.

Look into how SMB1 stores levels.  It's a nice simple approach that you can easily change depending on your needs.

Link to comment
Share on other sites

1 hour ago, Ecernosoft said:

It is very effective I know! It's also really hard to program too, I know.

1 hour ago, Ecernosoft said:

Btw by program i mean make the compression method, not the level data. Was thinking about doing something like that and using 16K extra RAM as a buffer.

You might not want to think about it as compression / decompression but more as efficiently storing level layout.  I suggested SMB because there was a lot of thought put into storing the level data in a "human readable/writable" format.  It wasn't necessarily designed to be compressed via a program... but drawn and compressed by hand.

 

I don't know how much you've dug into SMB level layouts but here's a basic overview:

 

General background ground layouts were determined (such as: cracked blocks at the bottom, 3 levels of brick platforms, etc.) which can be stored as a single object, and then the level drawing/"decompression" routine will repeat them until told to change.  And then other sets of objects can be set:  (1 rows of blocks, staircase of blocks, 1 row of coins, 3 rows of coins, etc), which can be done only for a single column or repeated.  There's also I believe a special code to make the block staircases.

 

So, the basic idea is to "compress" the data via design constraints... setup up your data to tell you what the layout is:  Start level with single ground platform.  At coordinate 1, start a run of coins... At coordinate 2, place a hole in the ground. At coordinate 3, place a power-up in a brick... etc.

----

 

You can throw as much RAM or ROM at the problem as you like, it's actually the easier thing to do... BUT I think a big part of the interesting challenge with these old systems (computers and game consoles) is to try and work with what you have available first before doing the "modern" thing and throwing a lot of resources at it.

 

I think you can get away without compressing your levels... with less levels and/or smaller levels with more content (maybe a little like Mappy)... but it's all a matter of what your design goals are.

  • Like 2
Link to comment
Share on other sites

1 hour ago, splendidnut said:

You might not want to think about it as compression / decompression but more as efficiently storing level layout.  I suggested SMB because there was a lot of thought put into storing the level data in a "human readable/writable" format.  It wasn't necessarily designed to be compressed via a program... but drawn and compressed by hand.

 

I don't know how much you've dug into SMB level layouts but here's a basic overview:

 

General background ground layouts were determined (such as: cracked blocks at the bottom, 3 levels of brick platforms, etc.) which can be stored as a single object, and then the level drawing/"decompression" routine will repeat them until told to change.  And then other sets of objects can be set:  (1 rows of blocks, staircase of blocks, 1 row of coins, 3 rows of coins, etc), which can be done only for a single column or repeated.  There's also I believe a special code to make the block staircases.

 

So, the basic idea is to "compress" the data via design constraints... setup up your data to tell you what the layout is:  Start level with single ground platform.  At coordinate 1, start a run of coins... At coordinate 2, place a hole in the ground. At coordinate 3, place a power-up in a brick... etc.

----

 

You can throw as much RAM or ROM at the problem as you like, it's actually the easier thing to do... BUT I think a big part of the interesting challenge with these old systems (computers and game consoles) is to try and work with what you have available first before doing the "modern" thing and throwing a lot of resources at it.

 

I think you can get away without compressing your levels... with less levels and/or smaller levels with more content (maybe a little like Mappy)... but it's all a matter of what your design goals are.

Hold on... I have an idea.

For a SMB->Atari7800 format.. we can make a 8*12 (96 byte) buffer, and have our level pointer (A).

Each "page" has C objects.

First we clear the buffer...

Makestuff

ldy #97; #1 due to the -1 in the Buffer stores

lda #0

Count

sta Buffer-1,y; minus one since we check for 0 afterwards

dey

bne Count

After that, we get A and check how many "objects" there are and store it in C.

Getplats

clc

ldy #0

lda (A),y

adc #1; add 1 due to compare to 0

sta C

 

inc A

bcc Noinc2

inc A+1; inc 16 bit

Noinc2

Afterwards, this code executes.

When we want to get a new "object" we do:

ldy #0

lda (A),y

asl; To get index into table

tay

 

And Y holds our platform type. (Note, in this example, only 128 possible platforms are available.)

 

We then have a table of subroutines that we can run, like this:

 

Platforms

       .word Floor

       .word Mushroom

       .word Wall

after the tay this code executes:

lda Platforms,y

sta B

lda Platforms+1

sta B+1; get pointer to subroutine

clc

inc A

bcc Noinc

inc A+1

Noinc

jmp (B)

Done; This is a label for subroutines to jump to (No rts because no JSR was executed)

dec C

lda C

beq End

jmp Getplats

End

rts

 

And there! That should work. Each platform has it's own subroutine that draws it. (Of course, to prevent crashing (if you run out of level data and into the "minus" world) you want to do an AND #%???????? for the # of bits to span all platform types and fill in the blanks with a nothing tile or one of the predefined ones.)

 

1 hour ago, Muddyfunster said:

Sometimes it's easier to start with boiling an egg instead of trying to boil the ocean.

Muddyfunster has a point here.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...