DIV ARENA FORUMS - Powered by XMB

Rip Off Revectored

dom cook - 13-5-2016 at 04:08 PM

Welcome to Rip Off 3 REVECTORED ...AGAIN

[Edited on 27-3-2019 by dom cook]

dom cook - 13-5-2016 at 04:16 PM

So lets begin with a brief description of what Rip Off is all about.

From the web;

Game Introduction
One or two players attempt to protect fuel canisters from groups of invading pirate tanks that appear from the edges of the screen. There are six styles of pirate tanks in the game worth 10 to 60 points each. The value of each style is determined by its speed and strategy. Low point value tanks are very slow and generally head directly for the fuel. Higher point tanks are much faster and may work together to lure a player to destruction.

All pirate tanks are armed with short-range lasers, while player tanks are equipped with a cannon. Invading tanks are destroyed when they are hit by a cannon shot. Enemies can also be destroyed by a collision with a player's tank. There is no penalty to the player for destroying enemy tanks this way except for the brief period of time he is out of the game. When playing a two-player game, it is not possible to shoot the other player, although you will both be destroyed if your tanks collide.

The game is organized into waves and bonus levels. Two or three enemy tanks attack in each wave. A wave ends when all the pirate tanks have either been destroyed by the players or have dragged a fuel canister off the screen. After a number of waves, the bonus level increases 10, 20 ... and another round begins, starting with 10-point tanks. Each successive round is slightly faster and harder than the one before it. The bonus level gives additional points for each enemy tank destroyed. The game proceeds in this manner until all fuel canisters have been "ripped off" by the pirate tanks.

Awesome or what?

If you chase two rabbits, both of them will escape.

dom cook - 14-5-2016 at 03:15 PM

PART 1 Getting started.

I've downloaded the original game. It comes with the PRG file which is editable in DIV studio. However, it can't be played because the media has been packed up using some strange magic.

The first thing to do then is to run through the code and identify all the missing media.
Once that's done I'll produce some simple place holders - beeps and boxes. This should get the program runnable through DIV studio.

In terms of game states, this will already be a finished game. Although perhaps a bit rough around the edges, it will already be playable and that's something that can't be said for anything else I've uploaded here recently.

In a way, that's the point of starting this project. To get something finished. I see my other projects stretching away into the future and I want to finish something.

PS. What's a paradox?

Back to basics

dom cook - 15-5-2016 at 07:57 PM

Stage 1 complete.
Objectives complete:
Ripped out the Mode 7 and converted coordinate system back to screen type
Neutralized sound commands
Set up some place holder graphics

The essential functionality of the game is now in place and it is even kind of playable even in this state.
The next step is to make some blocky graphics for the individual game elements so that I can employ the DIV collision detection functions for report various relevant events in the game (Moslty being shot.)
After that I need to determine the size and shape of the game area. As I want to make this game switchable between 2d and 3d, I need to figure out an arena form and size that works well in both formats. For a non scrolling top-down 2d game a rectangle that corresponds th the screen works best.. But for 3d a circular arena is perhaps more suitable. The original 2d game also featured wraparound gameplay (going off one side and coming on the other) this doesn't obviously translate into 1st person 3d. For 2D there's also the option of a scrolling screen to consider.

Attachment: RIPOFF301.PRG (20kB)
This file has been downloaded 3675 times

Attachment: RO.FPG (1.1MB)
This file has been downloaded 4027 times

dom cook - 16-5-2016 at 06:26 PM

DIV doesn't do collision detection in mode 7 so in the original version of this game collisions are reported when two objects get within a distance of less than the sum of their radii.
I've now realised that it's actually possible and quite easy to use DIV collisions even in Mode 7 or 3D. There's a demo of this in the code snippets thread on mode 7 setup.

So I've now stripped out the old collision detection routines and replaced then with DIV's collision(type process type) function. This required some slightly more beefy place holders so I've upgraded the graphics to rectangles. And for now I'm working with a rectangular game area.

As a bonus, thanks to Mike I've got to restore a lot of the original sound. The files are in the .zip

The game is starting to shape up. Go on, give it a go.

Attachment: RO.FPG (84kB)
This file has been downloaded 3969 times

Attachment: RIPOFF302.PRG (18kB)
This file has been downloaded 3659 times

Attachment: ripoff3.zip (79kB)
This file has been downloaded 3635 times

MikeDX - 16-5-2016 at 08:48 PM

Very cool DOM

Problem with PRG though, EXP.WAV needs to be EXP3.WAV (or rename the file, either is good)

Little swines keep robbing all the goods though, I'm pretty useless at this game. Also I can run faster than my bullets so that keeps it interesting

dom cook - 17-5-2016 at 01:11 PM

Yes bullets are a bit crap I think it's because they are copied from the white ball from billiards game in the example programs. Pirate lasers seem to come out of odd places too. And the tanks turn really slowly.
It will get better, I promise, Bullets and movement are up next for the treatment.
Even with usable armaments, it's still going to be very hard for one player. The original at least was definitely meant for 2 players. It's the original survival co-op. That's why you can expect me to plague you at some point for networking help.

dom cook - 17-5-2016 at 07:11 PM

This one's a bit more like it. And here's the missing WAV, I think.

Attachment: RO.FPG (83kB)
This file has been downloaded 3689 times

Attachment: EXP.WAV (27kB)
This file has been downloaded 3640 times

Attachment: RIPOFF303.PRG (17kB)
This file has been downloaded 3622 times

dom cook - 21-5-2016 at 08:02 AM

This version has graphics for the tanks based as best as I could manage on the original game. I'm not that keen on them myself but for out of respect and all that.
The point of it was to have something to build a vector model from. If you run the game you'll get 2 renders. the DIV one and a scaled vector one, They both use the same position data.

I got the vector data by plotting the vertices into the graphs and then reading them off in the program using get_real_point() and map_get_pixel()

The advantage of vectors is demonstrated as they scale nicely. Scaling a one pixel thick line drawn on a sprite by 50% makes it degenerate and scaling it up makes it fat.

Attachment: RIPOFF306.PRG (25kB)
This file has been downloaded 3333 times

Attachment: RO.FPG (117kB)
This file has been downloaded 3715 times

Now where was I?

dom cook - 12-9-2016 at 05:30 PM

What's needed for this and for any other potential 3d vextor games is a simpe way to make the models. Once you move beyond cubes and boxes it gets seriously tedious typing out the model coordinates by hand.

For that reason I'm trying to knock together a (very) simple 3d model editor prog which will be able to save and export files in a custom format. This too is tedious but once it's done it will be worth the effort. With Mike's blessing it could even possibly end up as an integral part of DIV,

Here's a shot of what I've got so far.
If there's anyone out there with any suggestions regarding potential features please let me know.

[Edited on 12-9-2016 by dom cook]

MikeDX - 12-9-2016 at 05:36 PM

Yes. We need this! Could be awesome for us as it would work well for making retro vector games especially mobile and web

time for a post

dom cook - 22-9-2016 at 04:27 PM

I've been pottering with this editor and it's coming on slowly. My problem is that I can't focus on it so I'm just doing the odd bit when I've got the time at the mental energy.

Seeing as it's been a while since I contributed anything here, I've decided to post what I've got so far.

You can't do much editing with it at the mo, apart from rotating, scaling and changing color of bodies. You can also delete objects and add blank ones.
Keys that do stuff are _n, _b, arrows, _1 to _5. _f1 to _f5. letters, backspace and enter (when you name a new object.).

Attachment: editorprg.zip (19kB)
This file has been downloaded 3347 times

MikeDX - 23-9-2016 at 12:22 AM

And here it is as a web app in all its glory

http://js.mikedx.co.uk/domcookeditorprg.html

dom cook - 23-9-2016 at 06:29 PM

Hey Mike I've been adding a tool which creates new objects and I'm encountering a problem where the program will just shutdown without warning or error message. I guessing that it's because the program is exceeding the maximum allowed number of processes. Is that feasible? I've upped the maximum number of allowed processes using the compiler_options and it looks like this might have solved things but it would be nice to know what was causing the problem.

PS Now you've made it into a web app I'm more motivated to get on with it. I'm a bit embarrassed with it as it is now.

MikeDX - 24-9-2016 at 12:08 AM

I think the max number of processes is pretty high in modern div.

The debugger should show you some stats. Also i think max processes is based upon how much memory div is allowed to use, so local vars really bump this up and lower the amount of processes you can actually use.

I should really change this and make it "infinite"

dom cook - 27-3-2019 at 04:16 AM

Quote: Originally posted by dom cook

PS Now you've made it into a web app I'm more motivated to get on with it. I'm a bit embarrassed with it as it is now.

Famous last words.
Three years later...

MikeDX - 27-3-2019 at 10:40 AM

What on earth are you doing up at 4am

dom cook - 27-3-2019 at 12:28 PM

it was 5 where I am. Still a bit too early though, I admit.

[Edited on 27-3-2019 by dom cook]

dom cook - 27-3-2019 at 05:55 PM

Ok so the 3d editor thing was a bit ambitious.
This time I'm focussing on making the game.

In getting familiar with the code again, I've already managed to break a couple of things but, not to worry, I've added a cool camera whose height can be adjusted by dragging a billiard ball.

Try it here..

Attachment: RIPOFF.zip (112kB)
This file has been downloaded 812 times

[Edited on 28-3-2019 by dom cook]

dom cook - 31-3-2019 at 04:01 PM

OK I've got some baddies to shoot again. I had the bright idea of purging the prg of user defined local variables. Not surprisingly this got me into a mess but I'm back on track now.

MikeDX - 1-4-2019 at 03:20 PM

http://js.mikedx.co.uk/ripoff010419.html

dom cook - 3-4-2019 at 08:21 AM

Right I'm at the point where everything seems to be working ok in 2D. This is pretty much a complete remake of the original Rip Off game now (minus any as yet undiscovered bugs). It's missing explosions and maybe some other effects and the pirates are terrible shots but it's the same gameplay. The next thing to do is swap the font for a vector based one and then I can start to 3d things up a bit.

Attachment: RIPOFF403.PRG (28kB)
This file has been downloaded 806 times

Wow, that was relatively painless.

[Edited on 5-4-2019 by dom cook]

Attachment: font0.FPG (15kB)
This file has been downloaded 810 times

[Edited on 5-4-2019 by dom cook]

dom cook - 5-4-2019 at 04:39 PM

Slowly but surely, 3D is on the way.

dom cook - 8-4-2019 at 11:13 AM

The 3D effect in the last picture was a result of perspective. The camera itself was fixed directly above the centre of the game area and pointing straight down.
This image, although not a lot more to look at is more complex, the camera can be tilted moved and translated so the view is from above and to the side. Of course not everything is getting the 3d treatment yet. I'm proceeding with caution. If this breaks badly, I don't think I have the resolve to try to fix it.

This is also a significant improvement on Div Tank Arena because the camera in that was locked in a horizontal plane. That's been something I wanted to put right for a while now as I quite like the idea of a wireframe dogfighting game and that would require a free camera.
So, at last I'm getting round to it, this time round, the biggest problem with making this step has been that I've had flu and fever for about two weeks and even the most simple concepts have been beyond my grasp. Trying to manipulate a bunch of vectors in my head has been horrificly difficult.

[Edited on 8-4-2019 by dom cook]

MikeDX - 9-4-2019 at 04:44 PM

This is very cool

Dom I've got a WIP page for uploading a zip of prg + assets, that creates a html file. Maybe we can use your WIP as a test for it

dom cook - 10-4-2019 at 09:47 AM

Sounds like a good idea, Mike. Where do I upload? Do I pack all the files fpgs etc into a .zip and send it here.

Progress update.

These screenshots show camera panning zooming and tilting in action. I've got some bug involving plusses and minuses gettting mixed up which I can't figure out so stuff is inverted but it's still progress.

dom cook - 11-4-2019 at 08:17 AM

Here's a wipzip.
The camera is now is tilted to give an overall 3d view of the game area and it's possible to testdrive the little tanks. Bullets work too but the baddies are turned off at the moment because I haven't made models for all of them. The tanks can shoot each other though so that's kind of fun.

(If you want to tilt the camera use _f1 and _f2)

Attachment: r0411.zip (120kB)
This file has been downloaded 824 times

dom cook - 12-4-2019 at 08:39 AM

Quick update: The camera can now rotate around its up axis. This means that it's got all the degrees of freedom it needs for this game. Now to mount it on a tank to get a first or third person view. What I want is for the game to have the option of choosing the view ranging from 2D (top down) to 3D 1st person. It would, at least, make a nice demo.

If you're interested, just swap out this prg with the previous one. Use _f3 and _f4 to rotate the view.
Attachment: RIPOFF412.PRG (45kB)
This file has been downloaded 809 times

dom cook - 16-4-2019 at 05:15 AM

Added a draw 3d line function so I can fill out the scene with a bit of background.

Swap this:
Attachment: RIPOFF416.PRG (52kB)
This file has been downloaded 813 times

dom cook - 17-4-2019 at 04:32 AM

Screen-wrap doesn't really work in 1st person 3d. So for this 3d/2d remake, two different playing spaces are needed. One for the 3d view option and one for the original top down 2d view.
The 2d version is played inside a rectangular area where anything off screen is out of the game and players themselves cannot leave the screen because they are either blocked or they reappear on the opposite side (screen-wrapping). The previous image with the grid woks for this.
The 3d area, however, is circular. In this case anything beyond the circumference is deemed out of the game, more like this.

MikeDX - 17-4-2019 at 04:53 PM

This is looking very cool Dom. I'm still trying to work on the zip uploader, as multi zips in one page seem to make things a little odd when put in an iframe.

The wips pages work because its one game per page but in an iframe it all goes a bit slow.

Watch this space! (not literally, but keep an eye out!)

dom cook - 17-4-2019 at 07:16 PM

Keep working on it man.

By the way, I think I might have the makings of some kind of robotic lawnmower game here.

dom cook - 22-4-2019 at 05:18 AM

Added second camera with split-screen

Attachment: RIPOFF422c.PRG (53kB)
This file has been downloaded 818 times

Vortigano - 22-4-2019 at 06:43 PM

Quote: Originally posted by dom cook

Added second camera with split-screen

div request for font0.graph==89; so i get error 121
get_point error a nonexistent graphic was used.
c = 0;
g = 89;
x0 = 0;
y0 = 0;

dom cook - 23-4-2019 at 03:13 AM

Oh yes, sorry.
I added a couple of font characters but neglected to upload the new font file.

Attachment: font0.FPG (16kB)
This file has been downloaded 791 times

[Edited on 25-4-2019 by dom cook]

Attachment: RIPOFF425a.PRG (52kB)
This file has been downloaded 807 times

Vortigano - 25-4-2019 at 01:58 AM

it looks very good

dom cook - 3-5-2019 at 04:52 PM

Fixed a few things like the pirates having stormtrooper tier shooting skills and dodgy collisions. There are other improvements but I can't remember what they are.

Progress might be slow but, so far, I'm pretty happy with the results.

Attachment: RIPOFF503.PRG (54kB)
This file has been downloaded 799 times

Attachment: RO.FPG (188kB)
This file has been downloaded 781 times

dom cook - 5-5-2019 at 05:20 AM

We are now entering the realms of playability.

Attachment: RIPOFF505b.PRG (55kB)
This file has been downloaded 816 times

[Edited on 14-5-2019 by dom cook]

Attachment: ripoff514.PRG (58kB)
This file has been downloaded 807 times

Attachment: RO.FPG (252kB)
This file has been downloaded 789 times

dom cook - 14-5-2019 at 01:21 PM

Added a simple blur effect, reminiscent of an old vector scan screen.

dom cook - 21-5-2019 at 06:18 PM

just an update. In case my computer crashes.

Attachment: FONT0.FPG (17kB)
This file has been downloaded 814 times

Attachment: ripoff521.PRG (63kB)
This file has been downloaded 771 times

[Edited on 21-5-2019 by dom cook]

MikeDX - 22-5-2019 at 07:49 AM

Great work dom, really nice effect there!

dom cook - 22-5-2019 at 11:15 AM

Thanks matey.

By the way it's very simple to do.
1: Make transparent screen overlay by creating a map the size of the screen and giving it a flags of 4.
2: set restore_type to no_restore.
You can tinker with the darkness (colour) of the overlay and the frequency that its drawn (e.g. every 4th frame) to vary the effect.

Alternatively, instead of making a process with a screen-sized transparent graphic, you can simply draw a rectangle over the screen. I think this is quicker.

[Edited on 22-5-2019 by dom cook]

Vortigano - 22-5-2019 at 02:14 PM

I messed up the assets and I cant run it

dom cook - 22-5-2019 at 04:02 PM

Here's everything.

Attachment: RIP3DIV.zip (130kB)
This file has been downloaded 805 times

MikeDX - 22-5-2019 at 06:31 PM

This looks and sounds stunning Dom

http://js.mikedx.co.uk/ripoff220519.html

Vortigano - 22-5-2019 at 07:25 PM

I enjoyed the game, the online version is slow (about 10fps on googlechrome win8 64)

MikeDX - 22-5-2019 at 08:28 PM

i get about 50fps on chrome on my mac, but its a fairly good spec one

dom cook - 22-5-2019 at 08:39 PM

It's also a bit hard.
Sorry about not cleaning up some of the debug info. The next version will be better.
FPS-wise, it's written for 60fps.
I'm getting 15 online which is great for checking that the bullet collisions are working properly.

dom cook - 27-5-2019 at 08:27 PM

I've been giving a bit of thought to how I should go about wrapping this game and have made a fun little text intro with a bit of plot background to give the game some depth. Without an intro a game like this is way too small and is unlikely to get a even get a second look. Also, to do the original justice, I've tried to capture the escapist sense of excitement and adventure that, even this rudimentary game would create back in the day. Arcades were magical places where just a few bright moving lines could transport you across time and space. The magic ingredient was imagination. Maybe that is what those energy cells store. Don't let the fokkers steal yours.

Attachment: ripoff527.PRG (70kB)
This file has been downloaded 726 times

title screen

dom cook - 31-5-2019 at 05:44 AM

I was working on a menu with lots of game options but in the end I decided it was all a bit too pointless. So I'm opting for simplicity, and to keep things simple and true to the arcade original the only option will be the number of players.

[Edited on 31-5-2019 by dom cook]

MikeDX - 31-5-2019 at 09:06 AM

This is so so cool.

I wish the web version was a bit more optimised though

dom cook - 31-5-2019 at 03:58 PM

Quote: Originally posted by MikeDX

I wish the web version was a bit more optimised though

Can anything be done to improve that?

dom cook - 31-5-2019 at 05:05 PM

OK it's not completely simplified. I have an orbitting camera to show off.

MikeDX - 1-6-2019 at 09:28 PM

Quote: Originally posted by dom cook

Can anything be done to improve that?

well, the resolution causes problems as div was never really meant to run at such high res. it draws ever pixel every frame, so we would have to employ such practices as dirty rectangles.

the switch to sdl2 properly would fix it, as each graph would become a gpu poly.

just a lot of work, and not something I'm overly familiar with.

640x480 was always about my limit!

dom cook - 2-6-2019 at 05:25 AM

Not familiar with dirty rectangles. GPU polies sound cool though.

The black chunk on the right (width 400 pixels) is only there for debugging purposes so the intended final resolution is more like 1000x800 or to be more conventional maybe 1024x768 which DIV did support. So maybe getting rid of that will help a bit. I'll upload a truncated version.

Just noticed that holding down F1 boosts the fps. Why might that be?

[Edited on 2-6-2019 by dom cook]

[Edited on 2-6-2019 by dom cook]

CicTec - 2-6-2019 at 11:37 AM

Quote: Originally posted by dom cook

Not familiar with dirty rectangles.

dirty rectangles is simply a rendering technique to improve the performance of the FPS in which, instead of constantly updating the screen entirely, the program keeping track (or not keeping track depending on the technique) of the graphs and their positions, updates only portions of the screen (or does not update).
This technique is embedded in DIV in the variables you know as dump_type and restore_type.

the first deals with a partial restoration (partial_dump) of the graphs (so it only updates the zones where in the next frame there will be a visual change from the previous one), while the second takes care of the bottom of the screen.

To understand how it works, you have to imagine the screen resolution as a sheet of paper, the bigger the sheet, the more things you can draw on it (like the resolution).
Now imagine having a small sheet, at the top left draw a triangle, at the top right a circle, at the bottom center a rectangle.
Now imagine having to replace the triangle at the top (so an update of the drawing, like a following frame) with a traprezio, what do you do? Well, just take the gum, delete the triangle (so the portion of the sheet where it is drawn) and draw the trapezoid in its place ...
The rendering doesn't work like that, in complete_dump, it takes the whole sheet, deletes everything, draws the new trapezoid and redraws the circle and the rectangle.
At this point you think, but lose more time in this way, and you are right, in fact, using partial_dump, do what you would do with the sheet, take only the area of the triangle, delete it and draw the new trapezoid, saving time (gain of FPS).
The problem with this technique, which has been abandoned over the years, is the one that works well when there are few areas to update (or few objects) but bad when the areas become too many, because it has to keep all the areas in order and delete them at one by one (and the iterative cycles are expensive) or worse still have to calculate any areas close to each other to merge a larger one (to have less areas to iterate), all calculations that eventually make it slower in terms of FPS than to erase the entire screen directly.

Quote: Originally posted by dom cook

GPU polies sound cool though.

The black chunk on the right (width 400 pixels) is only there for debugging purposes so the intended final resolution is more like 1000x800 or to be more conventional maybe 1024x768 which DIV did support. So maybe getting rid of that will help a bit. I'll upload a truncated version.

Just noticed that holding down F1 boosts the fps. Why might that be?

[Edited on 2-6-2019 by dom cook]

[Edited on 2-6-2019 by dom cook]

DIV is a game engine developed in the late 90s, where the predominant operating system was still MS-DOS and where the main PC models were 386 and 486 (pentium distribution was just starting), so it was designed , first for low-resolution games (given the limited power of the machines at that time), then the use of graphic acceleration did not exist in MS-DOS, all the rendering was done by the CPU so the games that developed were mainly VGA (320x200) someone up to SVGA (640x480), already a 800x600 resolution was a luxury, whether the graphics card and monitor supported this resolution, or whether the CPU could efficiently support all this computational load.

Today developing a graphics engine for the GPU has become the standard solution, the problem is that it works completely differently from developing a software engine like DIV, for example the technique of dirty rectancles is no longer used today, as explained, needs to trace information and iterate through them, modern rendering happens with the GPU through little information that is passed to them and the writing of small programs called shaders, which are written in a special language to be executed by the GPU, these programs have a support for conditional statements (such as IF) and iterations (like FOR) that are very low or absent, so it is not possible to implement such techniques in a GPU rendering, in addition to the performance defect indicated above.

In any case we always return to the starting problem, the GPU works by its nature in floating point and other features and the current DIV core does not support any of this.

dom cook - 2-6-2019 at 01:33 PM

So, what's the plan? Is anything happening about this?
As far as I can gather DIV development is esentially comatose and the prospects of a recovery don't seem too bright.
I'm not holding out much hope for DIV's future. But, hey, it still does what it does and is fun to play with and as long as it can do what I want it to do, I'm basically happy.

CicTec - 2-6-2019 at 01:48 PM

Quote: Originally posted by dom cook

So, what's the plan? Is anything happening about this?
As far as I can gather DIV development is esentially comatose and the prospects of a recovery don't seem too bright.
I'm not holding out much hope for DIV's future.

As I have indicated several times, everything starts from the necessary complete rewriting of the core, once this contains what the 21st century requires for the development of a game engine, you can think of being able to add what you want, but what a development plan have in mind Mike for the project seems to be unclear.

Quote: Originally posted by dom cook

But, hey, it still does what it does and is fun to play with and as long as it can do what I want it to do, I'm basically happy.

This is already important.

dom cook - 3-6-2019 at 08:10 PM

I've made a few additions and improvements so I figured it was time for another update/ backup.

My favourite new feature is the vortices that open up when the thieving 619905 break into the arena.

Attachment: ripoff604.PRG (71kB)
This file has been downloaded 723 times

I'm actually starting to enjoy this project now.

I'm not sure if these files have been updated but just in case, here they are.

Attachment: FONT0.FPG (20kB)
This file has been downloaded 730 times

Attachment: RO.FPG (252kB)
This file has been downloaded 697 times

Particle explosions

dom cook - 4-6-2019 at 05:58 AM

The particle setup I used for the vortices is easy to modify so I'm modifying it it for the explosions.

Of course, these are much cooler IRL.

Each player gets his own personal (colour-coded) explosion style.

[Edited on 4-6-2019 by dom cook]

Upon Reflection

dom cook - 7-6-2019 at 09:13 AM

In my opinion, for the first generation of video/arcade games to succesfully attract players some sort of plot was esential, These plots were, by necessity, simple. Think about Space Invaders or Asteroids and just compare what happens on screen with what the images are supposed to represent to understand how much of a part the imagination plays in making games playable.

Anyway, the plot of Rip-Off is as good an example of this as any. Space pirates stealing invaluable energy crystals or whatever. But, without some elaboration, the gameplay and the plot don't gel properly and that can cause some cognative dissonance which then leads to the spell being broken and the game not working. For example, How come you can respawn an infinite number of times? How can the pirates leave and enter the game area while the player's tanks will warp/wrap around to the opposite side? We could just remove the wraparound feature and imagine that the action is occuring in some sort of clearing or yard, but the warping is a big factor in terms of game play and removing it negatively affects the playability. besides, it can be a fun exercise to try to address such inconsistencies and originate a plot (however silly) that makes sense of them.

So, in this case, I imagine this conflict taking place in a subspace bubble, created as a hideout/stronghold for the storage of the valuable crystals. The pirates have found a way to break into this bubble, hence their ability to enter and leave the screen. The players, however, are locked in. They experience the screen as a nano-universe of sorts which they wrap around akin to being on a tiny planet.

Having adopted this notion, the next step is to represent it visually in the game. For this exercise I'm attempting this by adding some effects for when the objects interact with the boundary. As mentioned earlier I have a vortex, which is a classic way of representing a portal. This is for the pirates entering and exiting. The players, however, need something else, something which shows the containing effect the walls have on them while still allowing them to warp to the other side. For this I'm using reflctions. As they player's tank approaches the wall its reflection appears and increases in brightness as it gets closer. upon contact a strange telportoisis occurs.

Attachment: ripoff607.PRG (88kB)
This file has been downloaded 762 times

If you download this and want to try the wraporound feature you need to turn it on. Keys 1 and 2 turn it on and off, I'm not sure which is which.

[Edited on 7-6-2019 by dom cook]

dom cook - 10-6-2019 at 01:06 PM

As is usually the case when impulsively adding "cool" ideas, this reflection effect has turned out to be a little more work than expected. Confining the reflected image to the mirror required a bit of vector magic, including the line intersection code I thankfully (because I don't remember how to write it)
posted here a few years back.

In these images the reflections are confined by the upper edge of the mirror.

dom cook - 16-6-2019 at 12:39 PM

Finished reflections and added a few effects here and there.
So far so good.

Attachment: ripoff616d.PRG (93kB)
This file has been downloaded 716 times

[Edited on 16-6-2019 by dom cook]

dom cook - 27-6-2019 at 03:14 PM

Been working on the menu. This wrapping always takes way more code than it seems to be worth but a game is incomplete without it.

Most the work has gone into the demonstration which animates certain major aspects of the game.

Attachment: ripoff627c.PRG (127kB)
This file has been downloaded 673 times

..and have a good summer.