Jump to content

Photo

Scrolling Demo

Scrolling Z3 scrolling z3 zelda 3

  • Please log in to reply
12 replies to this topic

#1 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 06 May 2019 - 03:20 AM

Here is a video, and a GitHib repo, that demonstrates the approach to scrolling that I have discussed, using bitmaps.

 

 

The quest in the repo requires the absolute latest build, which will be out in the public domain later this week. If you want it sooner, feel free to send me a PM to ask for it.

 

This has proper solidity checking, but does not yet add support for any game events, or sprites other than the player. It also does not yet allow the player to 'pan' outside of the canvas, so he is locked in the centre of the screen at all times.

 

More may follow, but anyone is welcome to contribute.


  • Twilight Knight, Lightwulf and klop422 like this

#2 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 06 May 2019 - 09:02 AM

Hopeefully ot will be possible to limit scrolling to certain areas. Like continious scrolling in X axis and flip-screen in Y axis.


  • SkyLizardGirl likes this

#3 Russ

Russ

    Caelan, the Encouraging

  • Administrators
  • Location:Washington

Posted 06 May 2019 - 06:28 PM

It's cool and all, but this also seems excessively complicated. Moosh and I have a similar system running in 2.5 that seems a lot simpler (only 1/3 the side of your code) and, to me at least, infinitely more readable. I'm not even entirely sure what your method is doing. Creating several bitmaps and storing combo data, cset, and solidity in one each? It seems like a rather roundabout way of doing things. What's the purpose? I'm sure it allows for some added flexibility somewhere, but I'm not immediately seeing the benefit.

#4 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 07 May 2019 - 03:54 PM

It's cool and all, but this also seems excessively complicated. Moosh and I have a similar system running in 2.5 that seems a lot simpler (only 1/3 the side of your code) and, to me at least, infinitely more readable. I'm not even entirely sure what your method is doing. Creating several bitmaps and storing combo data, cset, and solidity in one each? It seems like a rather roundabout way of doing things. What's the purpose? I'm sure it allows for some added flexibility somewhere, but I'm not immediately seeing the benefit.


There are a few advantages here. The most immediately obvious, is lightweight ASM.

Don't count the size of the script itself--that's window dressing. Look at the ASM output from the script and count the instructions per frame, amd how heavy each of those instructions is to execute. ou are welcome to try to make a comparison, by taking he same map from this quest, making it scroll in all four directions and checking combo solidity when scrolling/panning, and comparing the size of the ASM output.

 

I'm running this single demo quest, faster than 1st.st runs right now. Granted, I have no sprites for ZC to track, but I would certainly expect old methods using stuff like DrawCombo() to be far, far slower. Also, count your loops, and how frequently ou need them. For the most part, I only have loops running on DMap init.

Because I am pregenerating all of that data, my mandatory per-frame instryctions are a few blits (memory block copy), and some pixel reads for pixel-precise solidity and collision.

 

A less obvious feature, is that, because I am using bitmap masks for type/solidity checking, I can distort each bitmap using the same calcs, and end up able to have the same level of precision in my checks.

 

Redarding readabilirty: If you mean from the perspective of someone used only to old, stock and common ZScreipt, sure, because you are not accustomned to seeing these types of statements and expressions; but not from a programming sense. It is no more or less readable than older scripts, if you understand the syntax. In fact, coming from most programming languages, it is probably more readable, and more logical.

 

No-one normally manipulates tile draws individially, en masse in any modern game engine. This is more or less hor ZC behaves internally, for example, when performing a screen transition.

 

The most critical implication though, is from the perspective of designing a toolkit for anyone to pick up and use. Wityh careful design, selection of script types, and integration into the UI, I can use this in a way that is portable, and thus, in a way that requires no programming/scripting knowledge on the part of the user. The end-user need only set the dmap script to 'Scrolling', and enter in some D arg values, to use it.

 

Thus, game construction is entirely via the ZQ UI, and the user need never even look at how it works, nor need to comprehend it, to make use of it. If you look at my latest commits, you will see that, for the stats menu, I'm using the string table to generate menus.

 

On another note, I can use various effects, such as transparency, anchoring, pivot and rotation to make all sorts of mad visual effects on the primary game screen, with only a few instructions, that take very little extra power to execute. In the DQ example, I make the menu display part of the game screen bitmap, and I make it translucent while not needed.

 

Look at levels in games such as the 16b Akamajou Dracula titles, for examples of using this kind of effect.

 

If you wanted to, e.g.) make a dungeon that slowly rotated, imaginge how much work you'd need to do to manually rotate and reposition individual combos--and the ASM generated by such a task. Instead of that, I can pivot the bitmap with rotational anchors, and move it on any desired axis, and do the same with its solidity mask, and its type/flag checking.

 

Further, I can use the entire screen area with this method, without clunky hacks. Because my master map is pre-rendered, I am just drawing a slice of it onto the full screen at all times. This is less of an issue in my implementation, as I do not need to blit enemy/weapon sprites above it, but I can see adding an option into ZQ to draw the subsceen before sprites, so that it is always possible to blit to the entire screen size, on layers 0 or 1.

 

Thus, i save screen real-estate that is normally wasted by the subscreen for something more useful.

 

Last, if I want a full horizontal scrolling, sideview level, I can arrange my bitmap to be any size to fit my need. if \i want it to be two screens high, by 64 screens wide, I have that luxury without any fancy combo pos and screen pos reading functions. e.g., i do not need to align multiple maps, in order to get 64 screens of width.

 

P.S. I could equally use mapdata->isSolid(x,y), and mapdata->Combo*[] here, if I don't need distortions or visual effeccts. I already installed *mapInfo.curscreen and *mapInfo.curmap, so that I can determien the actual map and screen for the current player position at any given time, on the 'real' ZQ game map. Thus if I want to cut down a tree, I could use that data location, modify the mapdata, and act accordingly (e.g.), write a different ComboD[] to that mapdata, and reblit only that screen slice to the master bitmap, which is then redrawn to the virtual screen.

 

I need only set that event oe time, if I  want it to be static; or I could instead write new data to its combo location on my bimaps, including solidity, type, and flag values, without ever touching mapdata, in which case, it reloads from the original mapdata when the player re-visits the area (i.e., the tree will be still be gone or will be back, respectively).

 

That is one simple 16x16 pixel block copy to (from) two to five locations, depending on how many calues I need up update. It's a total of 45 ASM instructions IIRC (this includes popping the dunction params), on average, to completely modify a specific position data in all five places, so that part may be heavier, but I need to do it far less frequently than shifting screen combos to create a scrolling environment


  • Lightwulf and SkyLizardGirl like this

#5 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 07 May 2019 - 06:30 PM

Updated Video

 


  • ShadowTiger, Twilight Knight, Alucard648 and 1 other like this

#6 ModernLink

ModernLink

    Newbie

  • Members

Posted 10 May 2019 - 02:07 AM

scrolling quest would be rad, I see theres still some way to go
  • SkyLizardGirl likes this

#7 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 10 May 2019 - 08:48 AM

scrolling quest would be rad, I see theres still some way to go

 
Some other videos:
 

 


#8 Reflectionist

Reflectionist

    Apprentice

  • Members
  • Real Name:Jake
  • Location:Missouri, US

Posted 27 June 2019 - 09:08 AM

Would there be a way to apply the scrolling unilaterally across all 2x2 screens? Just thinking out loud... Would be nice to effectively quadruple each screen's space to a 22x32 area.

(Also, thanks, Zoria. You're working your ass off on these things and its going to pay off huge.)

Edited by Reflectionist, 27 June 2019 - 09:09 AM.

  • ShadowTiger and SkyLizardGirl like this

#9 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 01 July 2019 - 03:11 AM

Would there be a way to apply the scrolling unilaterally across all 2x2 screens? Just thinking out loud... Would be nice to effectively quadruple each screen's space to a 22x32 area.

(Also, thanks, Zoria. You're working your ass off on these things and its going to pay off huge.)

 

Internally, this isn't happening for 2.55, however, making scrolling areas with dmap scripts should work using the system that I am developing.

 

My Scrolling.zh header allows setting the scroll area in screens_wide by screens_high.

 

I may need to expand max dmaps to make this easier on the end-user.

 When it comes to portable, easy to use Z3 scrolling systems, I fear that people will need to accept what people like me are willing to create and support.

 

The internal code relies far too heavily on screens having a fixed size. Years ago, JMan has a plan to set a screen area, but such a thing won't be likely to be internal for at least one version forward.

 

A scripted system will need to suffice for now. Keep in mind that my personal application does not need a number of ZC features, but that I am trying to make the same system support a Z3 style quest.

 

The code that I am writing for Scrolling.zh is something that I have been mentally planning for years. I knew precisely how I wanted it to work, and I planned engine features around my mental model.


  • ShadowTiger, Reflectionist, Lightwulf and 1 other like this

#10 Reflectionist

Reflectionist

    Apprentice

  • Members
  • Real Name:Jake
  • Location:Missouri, US

Posted 07 July 2019 - 09:18 AM

"My Scrolling.zh header allows setting the scroll area in screens_wide by screens_high."

That's what I meant, actually. By setting a scroll area to, er... 2 screens by 2 screens (taking the extra care to be consistent in that application) would strongly imply a larger screen.

Kind of like this - https://www.gamasutr...orld_Part_1.php

So I think we're on the same page. Thank you, that all sounds really awesome! Can't wait to noodle around with it.

Edited by Reflectionist, 07 July 2019 - 09:19 AM.

  • Lightwulf and SkyLizardGirl like this

#11 SkyLizardGirl

SkyLizardGirl

    Unbeknownst to danger we call upon your help

  • Banned
  • Real Name:Arianna Crystal Ritter
  • Location:Earthia

Posted 16 July 2019 - 01:43 AM

I really like this scrolling mechanic. I want to use it on maps that would take a very long time to get to the

other side of the screen without stressing out the player.  One map would be like a Desert that repeats itself.

 

ZNRHwUo.png

 

 

The scrolling would work in some maps, and deactivate in others when you enter the next map.

 

This could be good for Zelda Overworlds and then entering smaller areas by warp that then go back to the Usual ZC Zelda1 scrolling.


Edited by SkyLizardGirl, 16 July 2019 - 01:52 AM.

  • Lightwulf likes this

#12 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 17 July 2019 - 04:46 AM

I really like this scrolling mechanic. I want to use it on maps that would take a very long time to get to the

other side of the screen without stressing out the player.  One map would be like a Desert that repeats itself.

 

ZNRHwUo.png

 

 

The scrolling would work in some maps, and deactivate in others when you enter the next map.

 

This could be good for Zelda Overworlds and then entering smaller areas by warp that then go back to the Usual ZC Zelda1 scrolling.

 

This is easy to do, aye. The scripts support it.


  • Lightwulf and SkyLizardGirl like this

#13 SkyLizardGirl

SkyLizardGirl

    Unbeknownst to danger we call upon your help

  • Banned
  • Real Name:Arianna Crystal Ritter
  • Location:Earthia

Posted 19 July 2019 - 11:13 PM

This is easy to do, aye. The scripts support it.

 

Lol..*  That's the Giant Desert,  One of the Flying Beast Dungeon Fortresses was going to travel around

that Link has to jump to get into using the Roc's feather.


Edited by SkyLizardGirl, 19 July 2019 - 11:14 PM.

  • Lightwulf likes this



Also tagged with one or more of these keywords: Scrolling, Z3 scrolling, z3, zelda 3

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users