Things I would like to do for HEL 2

[Peter]

HEL 2.0 is the next major release. I will take the freedom to make significant changes to existing features. These changes will probably lead to incompatibility with existing sources. I will of course supply detailed information about changes and how to make your code compatible with the new library. Removed code from the library will be made available to you. You can copy/paste things from it, in case you need something what went out. (except for the rotation stuff from the map system though, i won't provide the sourcecode for it)

I decided to this step, because I don't like a couple of implementations in HEL anymore. And yes! I also don't like the incompatibility issue, it's something I always try to avoid and make everything downwards compatible. But I must break the law, in order to realize my vision of HEL. ;)


Here is a list with things I would like to do for HEL v2. Please comment and give me feedback!


1) Remove support for rotation maps. It seems nobody is using this feature and it would save a few bytes when it is out. It would probably even easier for me to optimize the non rotation algorithms then. As a side effect, a couple of other map functions would getting faster, since I don't need to check for rotation/non rotation anymore.

2) Support for wraparound in the mapsystem

3) Changing hel_MapInit* functions so they return handles instead of the TMapScrollInfo structure. This makes it possible for me to keep track of initializions and I could implement a reset function. It's also more common to other HEL functions.

4) Include TMapScrollInfo::UseParallax member variable in TMapScrollInfo::ScrollFlags bitfield and then remove TMapScrollInfo::UseParallax

5) Include TMapScrollInfo::BoundsCheck member variable in TMapScrollInfo::ScrollFlags bitfield and then remove TMapScrollInfo::BoundsCheck

6) Remove TMapScrollInfo::MapRedrawNotifiers and add these members directly to TMapScrollInfo

7) Remove hel_RAMEntryExists. The saving functions in HAM hardly work and I will wrote my own when I need them, so they will also go into HEL.

8) Removing hel_FadeInit and hel_FadeReset

9) Changing hel_FadePalette, so it does not expect a TFadeInfo parameter anymore. Just a value between 0..31. 0 = black, 31 = normal palette.

10) Rename hel_FadePalette to hel_PalFade

11) Removing hel_ObjUpdateInOAM, because it does not really work.

12) Pad System. Changing the default behaviour to PAD_BEHAVIOUR_PRESSED_ON_BUTTON_DOWN which makes more sense as many users reported. Now it is PAD_BEHAVIOUR_PRESSED_ON_BUTTON_UP. Maybe
adding a parameter to hel_PadInit, to choose either UP or DOWN behaviour.

13) Removing a couple of macros defined in hel.h, such as
+ VBAOUT
+ SET_POINT
+ SET_RECT
+ H_BG_CREATE
+ H_BG_DEINIT_SELECT
+ H_BG_VISIBLE_SELECT
+ H_BG_INVISIBLE_SELECT
+ H_FULL_DARKEN
+ H_WAIT_VSYNC
+ NEW
+ OBJ_COLORS_16 (not sure)
+ OBJ_COLORS_256 (not sure)
+ FADE_COLORS_16
+ FADE_COLORS_256

14) Changing order of members in TRect* structures. It should be Left,Top,Right,Bottom and not Left,Right,Top,Bottom. What a dork was I when I wrote that?

15) Removing OBJ_COLORS_16, OBJ_COLORS_256, FADE_COLORS_16, FADE_COLORS_256 etc and introducing PAL_COLORS_16 and PAL_COLORS_256 only

16) I would like to rename the hel_CustomText functions, because I think it's not clear for what they are, BG or OBJ. hel_BgText would make more sense imo.

17) Removing hel_CustomTextType.

18) Changing hel_CustomTextInit. Now you have to pass an half initialized TextInfo struct and the other half is initialized by the lib. That is foobar, uber foobar even! :)

19) I would like to add an own sin lookup table which is 512, or any other ^2 value, elements big. Just to avoid modulo operatorations which is a consequence of not using ^2 lengths. The Sin-Table in HAM is only 0..359 and you have to do %360 which is much slower than &511 for example.

20) A global hel_Init function which must be called once at the beginning to initialize some inner variables for the lib. Don't be scared, no nag-screen or anything like this planned!

21) Supplying the libs with different names. libhel.a and libheld.a where the trailing "d" stands for debug. This way you can have both libs in the library folder. If you need to switch between release and debug library you can just do it via the makefile, no need to copy the libs around.

22) Use the same directory structure as HAM, so you can directly unpack the HEL zip archive to your HAM directory and everything goes into the proper locations.

23) I would also like to add more info to the params, like microsoft did with their win32 console functions for example. They have empty defines which are called "IN" and "OUT". In their function declarations they have: void foo(IN int Handle, OUT void *pBuffer); for example. But the idea is very beta.


Feedback highly appreciated!

[blindfold]

Hi.

I think it is good idea, to move on to the next stage of the project, I'm not sure about 'lack of backward compatibility' programmers reactions. I think it's better to have solid (logical and technical) than have some drawbacks from older versions, so it is a good step.

I have never used some of the functions, so I will just speak for myself.

My short thought about only non scale/rot support:

I had many ideas/unseen features on GBA using scale/rot maps (not just mode7, like in my old KommandorGonzo). Using scale/rot maps without DTE is really hard, due to 256 tiles limitation - 256 tiles will cover just 1/3 of the screen, so you have to use dull graphics.
If removing scale/rot maps will increase speed of non scale/rot maps, I'm for it, however.


Keep going with great work Peter!!

[batblaster]

My friend,

anytime good ideas, only you will make me crazy to update all my code heheheh the release date of my game is near ( i do not want to lose my publisher) and i don't know if i will update all to 2.0 i think is dangerous for me to move to a non hard tested version...

I'm happy to know when you think to release to think if i'm in time to update or not...

Cu...

P.S. I wrote the new version of the Credits and you are at the top of the list hehehehehe

[Cube]

There is one big feature, I'd really like to see - sector maps (possibility to go from one map to another if they share the same tileset). Using this and map wrapping I could create great levels

Cube

[Peter]

Thanks for your feedback

I just found two further things that would be much better than the existing solution.

1) Feed hel_MapScrollBy directly with the parallax ratio as deltax/deltay

2) Remove hel_MapSetParallaxRatio and hel_MapGetParallaxRatio

[Peter]

Another thing that makes sense:

Being able to specify how many bits a tile uses for the tilenumber. So if the tilesystem is not forced to use 15bits, lets say you specify 11bits only, you have 4bits for whatever you need. Collision information for example. This is a good idea to save memory

[Chano]

1) Feed hel_MapScrollBy directly with the parallax ratio as deltax/deltay

That's a lot better than the Parallax functions.

You should also give background wrapping support. In my game I have to maintain two mapsystems (hel and mine) only for the wrapping thing. It's senseless.

Another idea is to make a customtext system with various sizes for the letters (for example, 8x8, letters, 8x16, etc).

[kouky]

hello,
It would be great for me to include a function to mirror an entire tile background:
mirror each tile + mirror each line of tiles

Thanks !

[Peter]

Hi,

It would be great for me to include a function to mirror an entire tile background:
mirror each tile + mirror each line of tiles

hmmm can you give me an example for what this can be used or is useful for?

[Chano]

Get a mirror circuit in a racing game?

[kouky]

I'm using animated tiled maps as videos.
Mirroring this kind of "videos" would be a very interesting effect for me !

[Peter]

I'm using animated tiled maps as videos.
Mirroring this kind of "videos" would be a very interesting effect for me !

hmm videos? Does it work? ... and how does it look like?

[kouky]

I've uploaded a demo here :
http://www.pikilipita.com/vj
(demo #4)

i've done my own tool to convert bmp to "video" for gba.
It's working quite well !
I tried to use your dynaimc reload method to display my videos, but it didn't
worked very well, what a shame !

And yes, a mirror effect is missing !

[Peter]

Hey, that's cool! What size has the final ROM and how long goes the vid?

[kouky]

So far, my ROM is 25 Mo.
Since it's only interactive video and mini games, it's impossible to say how long is the video.
Last week end, I was at a rave party as Vee Jay. I mixed with my cartridge + game boy player + game cube during one hour while a DJ was mixing drum & bass music.
It was a great time !

By the way, i've uploaded a new demo at the same URL