Editor rework

[brickviking]

A couple of points to think about. If you implement the wide-angle by stretching the 320x200 from 4:3 to 16:9 and making it wider that way (giving you roughly 360x200), then you'll end up with non-square tiles. If you put in more pixels to get your 16:9 and retain square tiles then most of the gameplay will be affected as the levels were presumably tuned for a 4:3 display. I don't know a good solution for either scenario.

I must say though, having used the ned editor in fullscreen (well, mostly) is way better than the cropped-to-4:3 version. I know exactly what I did to get it to work, but the change also affects nighthawk itself. The first section changes the number of pixels—and hence tiles—on screen, the second gives me a larger palette of tiles to select tiles from, given that I've now got more room to display them.

diff -u nighthawk-4.0/src/defs.h~ nighthawk-4.0/src/defs.h
--- nighthawk-4.0/src/defs.h~   2020-10-20 16:00:59.999414571 +1300
+++ nighthawk-4.0/src/defs.h    2020-10-23 22:20:11.944266834 +1300
@@ -73,12 +73,12 @@
  */
 #define SCR_ASPECT_43  (4.0 / 3.0)  /*JN, 04SEP20*/
 #define SCR_ASPECT_43_TOLERANCE 0.01
-#define WINDOW_SIZE_X 800  /*For screen size discovery. JN, 05SEP20*/
-#define WINDOW_SIZE_Y 600
-#define SCREEN_SIZE_X  320
-#define SCREEN_SIZE_Y  200
+#define WINDOW_SIZE_X 1600  /*For screen size discovery. JN, 05SEP20*/
+#define WINDOW_SIZE_Y 900
+#define SCREEN_SIZE_X  640
+#define SCREEN_SIZE_Y  400
 #define SCREEN_HSIZE_X (SCREEN_SIZE_X >> 1)
 #define SCREEN_HSIZE_Y (SCREEN_SIZE_Y >> 1)
 #define SPRITE_SIZE_X  32
diff -u nighthawk-4.0/src/edit_floor.cc~ nighthawk-4.0/src/edit_floor.cc
--- nighthawk-4.0/src/edit_floor.cc~    2020-10-20 16:00:59.999414571 +1300
+++ nighthawk-4.0/src/edit_floor.cc 2020-10-23 22:34:13.568267594 +1300
@@ -195,8 +195,8 @@
        SPRITE_SIZE_X + 6,
        (4 * (SPRITE_SIZE_Y + 10)));

-   ssp_block = sprite_sel_ptr & ~0x3;
-   for (ipy = 0; ipy < 4; ipy++) {
+   ssp_block = sprite_sel_ptr & ~0x7;
+   for (ipy = 0; ipy < 8; ipy++) {
        if ((ipy + ssp_block) >= flr_bm_size)
            continue;

@@ -205,7 +205,7 @@
            SCREEN_SIZE_X - 34,
            (ipy * (SPRITE_SIZE_Y + 10)) + 10);

-       if ((sprite_sel_ptr & 0x3) == ipy)
+       if ((sprite_sel_ptr & 0x7) == ipy)
            glColor4f(1.0, 1.0, 1.0, alpha_pulse);
        else
            glColor3fv(black_pixel[0]);

I also found something out, though I suspected it all along. I'm actually pretty crap at this game, I haven't survived past the second ship yet, so I guess you'll be the one to know how best this matches up with a decent challenge.

(Moved from issue #11)

[brickviking]

brickviking originally said:

... I must say though, having used the ned editor in fullscreen (well, mostly) is way better than the cropped-to-4:3 version. ...

-#define WINDOW_SIZE_X 800  /*For screen size discovery. JN, 05SEP20*/
-#define WINDOW_SIZE_Y 600
-#define SCREEN_SIZE_X  320
-#define SCREEN_SIZE_Y  200
+#define WINDOW_SIZE_X 1600  /*For screen size discovery. JN, 05SEP20*/
+#define WINDOW_SIZE_Y 900
+#define SCREEN_SIZE_X  640
+#define SCREEN_SIZE_Y  400

10 hours ago, jsno8192 asked:

To make the game wide screen, we could make the virtual screen 320x240. This will set the screen aspect to 16:9.

Actually, that works pretty well. There's no distortion I can notice.

10 hours ago, jsno also asked:

Hmm, interesting. I've never tried this :)

When you did the above change (virtual screen size to 640x400), did this make the sprites smaller on the screen ?

Given the above change, I thought that 640x480 might be a better fit. And yes, assigning 640x480 certainly made the tiles smaller; ideal for floor editing, though not quite so ideal for game tuning due to the viewport not being the same as the normal game. Still, it's not bad. I've included a snippet of my first—and so far, only—level.

I've yet to create droids, or even a ship map. This'll take me a while.

[jsno8192]

Well, if you like that screen size, then I think put it in to 4.0 (this change does not impact the game). Your code changes look good (just initial, date, comment in the defs.h and edit_floor.cc file etc). I agree, it makes editing floors easier.

Good pick up. Well done :+1:

[brickviking]

I'll get it started, though I'll have to add a #ifdef NED section and maybe drop a define into CMakeFiles.txt.

[jsno8192]

As long as you are only changing the CMakefile.txt file locally. I prefer you not to upissue the CMakefile.txt file in 4.0, because its been tested and is apart of the freeze.

Nb/ Once you create the makefile using cmake (ie: ~/..cmake ../nighthawk-4.0). You don't need to run it again unless you are changing the file structure of the source tree. So once you set BUILD_NED, you don't need to set it again. You simply, edit the above defs.h and floor_edit.cc files and then run "make". After that, you do your normal git actions to commit the change.

Before I touch the source code again, I'm going to have to play with git a bit more. You'll probably see a dirtectory called "test" appearing in the attic directory (and then disappear) :).

[brickviking]

If I modify the relevant variables in defs.h, that's great, but I can't get cmake to pass through a BUILD_NED to the compile environment. Any ideas here? Presumably if I was building ned, I'd be adding a -DBUILD_NED switch to the compile, but not for nighthawk.

[jsno8192]

I've just realised, if you edit the defs.h file, you will change the game as well. So, no. Don't do any changes to defs.h and floor_edit.cc in 4.0. We'll address this issue in 4.1dev.

To compile ned, you have to run "ccmake ." after you have run cmake. ccmake will let you toggle the BUILD_NED definition.

[brickviking]

I was aiming at a more one-stop-shop for compiling ned without having to adjust defs.h, but when I tried putting the changes into edit_floor.cc instead, I was ending up with some issues with the right hand side of the screen not being rendered. so I gave up on that idea. In essence, I don't see ned's source code changing much over the next little while, and I've got a working "large-mode" ned. I'll stick with that for the moment if I need to recompile ned for whatever reason.

[jsno8192]

No worries :)

I'm going to have a play with git and familiarise myself a little bit more with it before I start modifying the game (checkout, update, commit operations etc).

When I do modify the game, should only be a handful of little "one liner" fixes.