soulweaver91 / project-carrot Goto Github PK

This would resolve the issue of distributing asset packs manually. It would need to understand the structure and contents of (the multiple versions of) Anims.j2a, pull sprites as mandated by some resource list and reconstruct them in the formats the game understands.

Partially blocked by #3, as actually using the gunpoint etc. metadata from Anims.j2a as well would be sane, but that data could only be used after the graphics system is fixed.

The primary focus, once development resumes, should be to implement the missing events that are often required for level navigation:

• Hooks (variation of vines)
• Springs, priority on vertical ones
• Platforms
• Tubes
• Collapsible scenery
• Float Up
• Speed destructible scenery

While the end goal is to replicate the whole engine, an "interactive level previewer" is an important point that should be reached as soon as possible.

The title says it all. No reason to use the macro version.

Ever since the colored text was added it was clear that SFML's sprite coloring was not really suitable for this at all, but now it can be overridden, so do that. (JJ2 probably just used a different part of the palette; that's something not worth it though.)

Blaster shots disappear noticeably earlier than they are supposed to especially when shooting against a slope.

Tests on the main QoB level indicate about 450MB of memory, with one huge spike while loading the level (first guess: layer sorting isn't done in-place). It should be possible to reduce this.

Some warps work the way they are intended to, for others the correct target cannot be found. The affected warps seem to be consistent between runs. Verify whether this is a bug in the game engine or in the level converter.

Bonus warps have already been assigned a temporary event ID 0x010D. Implement the split and the logic behind them.

This mostly happens when changing the window size very slowly. This has to do with the nature of the sf::RenderTextures, which are essentially frame buffer objects. In OpenGL context, the Y axis is flipped for FBOs, which is taken into account with SFML's display(). During the resize, there seems to be some kind of race condition that causes the wrong (non-displayed) buffer of the view to be drawn – of note is that the player OSD is always correctly drawn.

Attempts to add additional clear() (for a black render) or display() (for correct orientation image), as well as using a mutex to restrict drawing order, did not succeed.

Alpha Release One will be focusing on having the Shareware Demo episode fully playable, implementing all of its events with a few specific exceptions. These are (or should be, unless I missed some) the events that are used in the three levels and their completion status.

• Hurt
• One Way
• Warp
  • Set Lap and Show Anim parameters are not implemented, but the first is MP-specific and the other one is probably not used at all.
• Warp Target
• Trigger Area
• Trigger Crate*
• Buttstomp Scenery
• Destructible Scenery
• Vine
• Save Point
• Jazz Level Start
• Bouncer Ammo
  • The weapon itself is not close to finished yet.
  • Powered up Bouncer has not been implemented at all.
• Toaster Ammo
  • The weapon and its powered up version still could use some tweaks.
• Freezer Ammo
  • A good base for the weapon has been added.
  • Powered up Freezer has not been implemented at all.
• Stop Enemy
• Horizontal Blue Spring
• Red Spring
• Green Spring
• Blue Spring
• Blue Gem
• Red Gem
• Gold Coin
• Silver Coin
• Hook
• Peach
• Cake
• Orange
• Lemon
• Chips
• Cupcake
• Float
• Ricochet
  • A poorly working algorithm exists, but it needs more work. Relies on #7.
• Area End of Level
  • It's pretty much just the black cutout effect that is missing. It's good enough for now.
• Set Light
  • Color and flicker parameters ignored, their niche feature might be looked into later.
• Normal Turtle*
  • Random noises and in-place withdrawing are missing.
• Tube
  • Wait Time parameter not implemented. Needs to be checked if it is used in these levels.
• Text
• Belt Right
• Gem Stomp
• Spaz Level Start
  • Spaz doesn't exist yet at the moment, but the level start event is there and works.
• Limit X Scroll
• Activate Boss
• Flickering Light
  • See #29
• Ambient Sound
• Wind Left
• Carrot
• Full HP Carrot
• One Up
• Ammo Barrel*
• Gem Barrel*
• Ammo Crate*
• 1UP Crate*
• Bomb Crate*
  • Will be empty until the next one is implemented:
• Scenery Bomb
• Bouncer Power Up*
• Fire Shield*
• Sucker Float*
• Sucker*
  • As an extension of the above, even though doesn't appear as an event by itself.
• Lab Rat*
• Dragonfly*
• Madder Hatter*
• Bee*
• Bubba Boss

Events marked with an asterisk also need some kind of particle effects mechanism when they are destroyed/killed, though that may not belong to the scope of AR1.

These minor events specific to certain tilesets or niche situations will not be required (but may appear if adding them in is easy):

• Caterpillar
• Witch
• Small Tree
• Cheshire Cat 2
• Eva Earlong

Complex ones that won't be included at that time:

• Birdy

A lot of object pointers are passed around in quite a carefree way at the moment. Take some time to go through the relations of the core classes in particular and stop exposing the whole objects in places where it's unnecessary.

The interface should provide high level utility functions rather than providing direct access to things like the sound system.

Continuation of #18.

(Split off of #27.)

PC crashes on a Vista x64 VM right after starting up. The crash occurs while trying to set shader parameters, which is odd, because it gets past the initial GPU checks just fine (reports as shaders available and same maximum texture size as in the host OS itself) and apparently the shaders themselves also load properly as they didn't trip up the temporary asserts either.

Stack trace:

Child-SP          RetAddr           Call Site
00000000`0026aca0 00000001`3fb64f45 sfml_graphics_2!sf::Shader::setParameter+0xa
00000000`0026acf0 00000001`3fb6ac4a image00000001_3fb30000!CarrotQt5::loadLevel+0x7f5 [k:\project carrot\carrotqt5\src\carrotqt5.cpp @ 496]
00000000`0026aed0 00000001`3fb49565 image00000001_3fb30000!main+0x5fa
00000000`0026b0a0 00000000`6d8bc4c2 image00000001_3fb30000!QVector<std::weak_ptr<CommonActor> >::reallocData+0x805 [k:\qt\5.6\msvc2015_64\include\qtcore\qvector.h @ 607]
00000000`0026b0e0 00000000`6d934206 Qt5Core!QMetaObject::activate+0x592
00000000`0026b200 00000000`6d8c0f28 Qt5Core!QTimer::timeout+0x16
00000000`0026b230 00000000`6dc97f82 Qt5Core!QObject::event+0x68
00000000`0026b3d0 00000000`6dc96935 Qt5Widgets!QApplicationPrivate::notify_helper+0x112
00000000`0026b400 00000000`6d89b9d9 Qt5Widgets!QApplication::notify+0x12f5
00000000`0026ba60 00000000`6d8e50ac Qt5Core!QCoreApplication::notifyInternal2+0xb9
00000000`0026bae0 00000000`6d8e2e6d Qt5Core!QEventDispatcherWin32Private::sendTimerEvent+0x10c
00000000`0026bb40 00000000`6dc97f82 Qt5Core!QEventDispatcherWin32::event+0x1ad
00000000`0026bbb0 00000000`6dc96935 Qt5Widgets!QApplicationPrivate::notify_helper+0x112
00000000`0026bbe0 00000000`6d89b9d9 Qt5Widgets!QApplication::notify+0x12f5
00000000`0026c240 00000000`6d89d6ce Qt5Core!QCoreApplication::notifyInternal2+0xb9
00000000`0026c2c0 000007fe`f127231f Qt5Core!QCoreApplicationPrivate::sendPostedEvents+0x21e
00000000`0026c370 00000000`6d8e4065 qwindows!qt_plugin_query_metadata+0x246f
00000000`0026c3a0 00000000`7778d53e Qt5Core!QEventDispatcherWin32::processEvents+0xe05
00000000`0026c4b0 00000000`7778d7c6 USER32!GetWindowLongPtrW+0x176
00000000`0026c570 00000000`6d8e37a6 USER32!GetMessageW+0x232

Lines 494 to 496 of CarrotQt5.cpp at the time were as follows:

494:            windowCanvas->draw(loadingScreenSprite);
495:            BitmapString::drawString(getCanvas(), getFont(), levelName, 400, 360, FONT_ALIGN_CENTER);
496:            windowCanvas->updateContents();

It is a mystery as to why the execution even is in the loadLevel function in the first place, as the game should be entering the menu, not a level, as no filename was sent as a command line parameter.

soulweaver91/project-carrot-pcae#1

Implementing this will improve compatibility of Project Carrot. (Right now, PC crashes in SFML code on a virtual machine for instance.)

It's kinda ugly to do it this way.

Currently, nothing happens if you die while having no lives left.

Find what was changed in the movement code earlier (manually, since it was before the git reinitialization and back then the commits made no sense) since this didn't happen at one point. A good place to test this is the secret two gold coins alcove in Dungeon Dilemma.

Currently, keyboard input is partially processed via Qt's events and partially via SFML's; make it so that these both use the same system. Required for customizable key bindings later on.

(AFAIK, the rationale for this was that one of these had better support for held-down keys and one for additional distinction between left/right modifier keys. That needs to be solved.)

Currently, from the technical standpoint, the game window is designed in a way that splitscreen multiplayer is not possible. Add a view model layer and move some player-specific data, like score, from the game view code to the player code both as a variable and as a piece of drawing code.

TileMap should only handle the level layout and let the graphics be handled elsewhere.

• Jazz uppercut and savepoint animations were previously split in two because they were easier to implement that way. Fix the implementation.
• Gems were manually colored, each color in a separate image file. Implement a way for sprites to dye themselves instead.
• Gem sounds were manually pitch-shifted and saved at multiple stages. Find out how to do this with BASS FX instead.
• Find out if there are less obvious things that also broke.

Currently, each actor manages its own graphic assets individually. Objects of same class read the same assets multiple times in memory, which is obviously a very bad idea.

To fix this, implement a graphics cache: once a level starts, find all objects that have been used and call a static graphics bootstrapping static method on each. Load one copy of each sprite at most even if it was requested from multiple different objects. Keep the sprites in memory until the end of level or end of game. The object constructors need to be adapted to this.

Also, while changing the way the graphics are loaded, externalize the previously hardcoded values from the code to data files (XML or equivalent).

Preferred style uses lowercase-starting-camelcase for all self-defined methods, fields and local variables, and uppercase-starting-camelcase for all classes, namespaces, enums and typedefs. Arguments should also be separated with spaces.

Go through all the old code to fix these.

More than one animation should be supported at the same time.

From a glance, most of they seem to fit into a few categories:

• class fields initialized out of order
• noop const qualifiers
• operations between unsigned and signed variables
• not explicitly running enum items we aren't intending to handle through default
• unused parameters
• missing override qualifiers

Can happen at least when approaching from the right.

The same texture size issue already noticed with asset textures also most likely plagues tilesets, only in vertical direction instead of horizontal this time around. This should also be looked into later.

EventMap::getPositionEvent doesn't check properly if the coordinates given to it are within bounds.

• Add support for the rest of the bridge types.
• Fix the poor collision checking leading to walking over it looking more like falling in place.
• Fix the "on/off" binary stateness of whether a player is on the bridge.

It didn't come back even after going far enough to deactivate and reactivate it. I assume something somewhere cleared its tile in the event map, but what and why is unknown.

Right now there are multiple places where error handling is very thin or non-existent. Improve them.

Note: Caption tile type will not be supported as the default window border will be used.

The lighting system has to be able to handle:

• The lighting inherent to the player in each view
• An unlimited (not really, but at least implemented in a way that a max number doesn't end up as a problem) amount of light sources
• Two light layers: one behind the actors, where all the intense light caused by running, bullets flying, etc. resides, and one in front of the actors, for the regular lighting effects

While terrain collision checking uses plain hitboxes (at least for the player), collisions between actors should use the current animation frames to deduce whether they collide. Make sure to add in support for rotated sprites as it will be required for events like the poles and Small Tree.

Find out an efficient way for implementing this.

Positioned sound will make e.g. noise made by enemies way more natural, as nearby sounds would play normally and far sounds wouldn't. BASS does provide functions for them so use them.

Basically the same thing as what was already done with the menu system earlier. CarrotQt5 should primarily work as the arbiter between the UI, input, sound system and the menu/gamestate manager.

Can be fixed by resizing the window by any amount, but initially the size is based on an assumption of the window frame dimensions. Would be expected that this is the case not only in Linux but also in other Windows versions than the one the .ui file was last edited in. The game view should resize the window on launch to fit itself at 800×600 exactly.

The intended behavior was that exactly one of the shells (the faster one) would run the collision code and react accordingly by moving backwards until the shells no longer collide and set the speeds of both shells to go to opposite directions. What can happen is that the shell teleports to the other side of the collision partner shell instead and the two shells somehow collide repeatedly each frame until one of them is destroyed.

Simple use case example: https://source.openmpt.org/svn/openmpt/trunk/OpenMPT/contrib/libopenmpt/libopenmpt_bass.c

Other formats should probably still be played with BASS directly.

There isn't really any reason not to, other than that converting to them now might take some time.

Right now, the core timer is based on QTimer. It only supports intervals rounding to whole milliseconds, so effectively there is a new frame every 14 ms instead of the desired ~14.29 ms, resulting in an effective FPS of ~71.43.

There should be a way to bring this to exactly 70 FPS. (Ideally, game logic loop should be separated at some level from the graphics loop anyway – right now they are tied together very closely.)

Rather than having all menu functionality in one class, have each unique screen as its own class and implement the menu system as a stack of those screen classes.

The level manager could potentially also be put on the stack, so a pause menu could work in top of it easily.

Use lambdas where possible – even in the simple cases, a lambda can call a single function, so pointers are not really needed.

Pinpointing which sounds they are supposed to use is harder than it should be, though. The swish sounds under common set are the most likely culprits, but they may need speed reduction with currently unknown factors.

Even though the game supports arbitrary window resolutions, only 800x600 and below are fully usable because of some display issues:

• The somewhat hacky method for parallax effect currently always assumes a height of 600px and so the horizon will just be blank at the top and at the bottom.
• The width of the view is only set up when the level is loaded and not updated when the window size changes.

(At least in an almost pristine Ubuntu 16.04 VM.)

• Music occasionally starts with the wrong tempo in the menu.
• Level music is apparently searched from the wrong directory (files are fine if loaded via the debug menu). This might be a case sensitivity issue, though (in which case it's pretty much "tough luck" for auto-converted levels at the very least). That was exactly the case.
• 3D sound seems very choppy at least with many sounds playing at once.
• BASS FX pretty much doesn't work, after any processing the sounds come out as jarring screeches.

This was originally by design with the assumption that that row is not used for actual terrain, but it seems some levels actually go that low, so collision should be checked normally there as well with an invisible solid row added to below the screen instead.

Easily seen for example in the Labrat levels, where the conveyor belts and background computers look jumbled up.